Jerry Luo的博客

前言 到目前为止，所有事情都有一个共同前提：你在场。你打开终端，你描述任务，你 review 结果。agent 再能干，也是个需要被召唤的东西。 这个前提有个天花板。有些活它的价值恰恰在于”不需要人记得”——每天扫一遍卡在审批里超过七天的单据、每周检查一次有没有新的安全公告、每次有人提 PR 就先过一遍规则。...

前言 这四个词是目前 AI 开发工具里最容易搞混的一组。它们都能”让 AI 更懂你的项目”，都是往仓库里放几个 Markdown 或 JSON 文件，文档里的示例看起来也差不多。 于是常见的结果是：一个团队把四种都配上了，.github 下堆了十几个文件，用起来还是不顺——因为每一个都在解决不同的缺口，配错了...

前言 地基打好之后，agent 已经能自己跑很长一段路了。新问题随之而来：它跑得太远。 你说”帮我实现发票附件功能”，二十分钟后它交回来一个改了 23 个文件、加了 1180 行的 diff，附一句”已完成，测试通过”。 你打开 diff，看了三分钟，关掉。因为你根本 review 不动。 于是你有两个选...

前言 有个场景大概你也遇到过。 周二你和 agent 折腾了一下午，把 ExpenseFlow 的审批流从”单级审批”改成”按金额分级”。中间试过三种设计，前两种都因为状态机会出现不可达状态而废掉，最后选了第三种。过程很痛苦，但结果不错。 周五你让它加个”审批超时自动升级”的功能。它张口就来：“建议在 Ex...

前言 上一个环节解决了 agent 有没有手脚，这一个环节解决它知不知道规矩。 差别是这样的：你让它给 ExpenseFlow 加一个”差旅补助”类别。没有规矩的时候，它会新建一个 TravelAllowanceService，在里面写 if (amount > 2000)，金额用 double，时间用...

前言 有个问题值得先想清楚：为什么同一个模型，装在编辑器里和装在终端里，干活能力差这么多？ 答案不在模型，在它能碰到什么。编辑器里的补全看得见你光标附近的几百行；终端里的 agent 能 ls 整个仓库、能跑 dotnet test、能读到编译器报的错然后回头改代码。前者是个会写字的助手，后者是个能自己闭环的...

前言 同一个团队，同一份 GitHub Copilot 订阅，两个人的产出可以差出一个数量级。 一个人用它写出了完整的功能分支，PR 里三十几个文件，同事 review 完只提了两条意见就合了。另一个人也在用，但用法停留在”补全一行 LINQ”，稍微复杂点的需求让它写，出来的东西命名不对、依赖注入的写法和项目...

前言 上一篇 什么是 Harness Engineering 里，我们聊了模型之外的那一整圈基础设施。这篇聊的是站在那套基础设施之上，工作方式本身发生了什么变化。 先感受一下这个变化。同一件事，两种做法： 做法一：你打开聊天窗口问「C# 怎么给 HTTP 请求加重试？」。它给你一段代码。你复制，粘贴进项目，...