Enter your search text in the box above

Select a result to preview

Coding Agent 使用分享

最近在公司内外部做了几次关于 Coding Agent 的分享，收到了一些好评。整理了下内容，分享给大家，相信应该有些价值。

内部分享中有比较多具体实践，涉及到内部项目的信息就略过了。这篇文章主要关注于 AI coding 的思维转变方面。

Coding Agent 产品推荐

对程序员来说，直接使用顶级的模型和产品是最节约时间 & 金钱的。除非某个工具/模型的口碑广泛传播开了，可以再尝试一下，例如最近的 Kimi-K2.5。

可以做个思想实验，如果现在给你以 1⁄10 的价格，使用 sonnet 3.7 模型，你是否愿意？虽然可能弱一些的模型能在 80%任务上做得跟顶尖模型差不多，但我们仍然需要花 100%的时间去判断它的工作产出，付出额外的时间去 debug 和调整。在后面的章节中我们也会提到，随着模型产出质量、自主性的提升，对于我们整体的工作方式都会产生巨大的变革，已经不仅仅是线性的提升了。

26 年 2 月的推荐：

Codex 的 token 用量计费情况

以上图为例，模型厂商 20 美元的订阅费，能提供超过 100 美元的 token 用量。这一点往往是 Cursor 等第三方厂商无法比拟的。

可以关注的产品：

Codex VS. Claude Code

这两个顶尖产品之间的对比一直是个热门话题。

我的产品比较方式如下：

让 agent 做多个 merge request 比较

比如上图中，Claude Code 也认为 Codex 的实现更好。

用这种方法测试下来，在我的 Python 项目中，Codex 相比 Claude Code 的胜率大概接近 80%。

远程开发

通过自然语言就能完成大多数的开发任务，我们自然会想着在手机端是不是也能随时随地指派任务给 agent。

一种方式是使用 Codex, Claude Code，Jules 等产品提供的 web/app 版，随时随地可以启动 agent 任务。这些产品一般与 GitHub 紧密集成，像 Codex 的整体体验非常不错，能够在手机上完成端到端的开发、review、修改迭代、合并等全流程。

缺点是使用沙箱环境，一方面每次启动都是干净的环境，无法保留上下文信息；另一方面沙盒自身具备的能力也有限（相比自己用的开发机），所以目前的场景仍然比较受限。

受到“大龙虾”的启发，我们也可以把本地电脑改造成“云服务”，能够有更持续的 session 和完整的工具能力。

初看这种方式还挺美好的，不过稍微深度使用一下，会发现happy这个项目本身维护还是有些不及时，会碰到底层 coding agent 功能迭代后 happy 还没有适配的情况（需要 vibe 改进一下）。所以我又安装了 termius 来做一些尝试。今年还可以期待一下 iPhone 折叠屏版本的推出。

第一阶段：100%代码由 AI 生成

之前的文章 分享过很多具体的工作流，这里不再详述。主要聊聊一些 mindset 和工作方式上的变化。

首先是追求 100%代码由 AI 生成，之前看到类似文章时我觉得有点噱头，有点刻意。但后来发现这背后存在着非常大的工作方式的差异。

比如我们只使用 Cursor 的 tab 补全功能，也能做到 50%甚至更多的代码是由 AI 生成的。但这显然还是“古法编程”的范畴，只是效率可能有略微提升。

接下来可能是你给 agent 发一个 prompt，然后就等待它产出代码，后续再做一系列的手工修改。这样仍然是一种比较舒适的“in the flow”的工作方式，初期会感觉效率爆棚，但实际统计下来（例如 斯坦福做的那个研究），可能总体效率的提升仍然是在 10%上下的范围。

追求 100%代码由 AI 生成，是你真正把 agent 看作“虚拟员工”的第一步，会让你的思考重心有非常大的转变。

Generation is Cheap

在追求代码 100%由 AI 生成过程中，最大的一个思维转变在于，“写代码”现在是一项成本很低的工作了。

经常碰到的 2 个误区是：

当我第一次意识到生成代码是很便宜的之后，我的工作逻辑发生了很大的变化。我们唯一需要评估的是，为了达到最终理想的代码产出，人类的注意力投入是否超过了某个成本基线。

例如 AI 生成的代码 80%以上都是正确的，只有少量细节，可以在 3 轮 prompt 内搞定，那么你需要额外投入的输入+审核时间并不会太多，就可以继续推进。

即使感觉 80%左右都是对的，但感觉一些“大方向”上有点跑偏，你需要额外投入很多时间做方向的说明和架构的 review，那么就可以大胆地git checkout .，完全丢弃掉这一轮的生成，修改 prompt 或者拆分任务后再来。

加上 LLM 当前在干净的 context 下明显工作得更好，所以新开 session 重新再来，收益不仅仅在于厘清了思路，识别了 agent 容易进入的误区，LLM 的整体注意力也会更加集中。

把这个认知进一步延展，我们可以尝试很多以前几乎不可能的做法：

推广到 AI native 的思维，在行动成本极大降低，专业技能门槛也大幅降低的情况下，我们需要更多的行动和迭代，而不是过多的方案思考与设计。

Spec

在碰到简单的 prompt 产出效果不好的时候，绝大多数人的第一反应是应该像之前的“瀑布式”开发那样，给 agent 提供非常详尽的 PRD/spec，让它们基于此来开发。

甚至 OpenAI 的研究员还表达过一个观点，认为未来自然语言的 spec 将会成为代码库的核心。

Spec 可以当代码吗？个人并不认同。一方面自然语言 -> 代码是个不确定性的过程，软件的基座部分仍然是需要高度确定性的（权限、审计、数据记录与处理、高频复用的业务逻辑等）。

另一方面，自然语言天生就有不可消除的多义性和模糊性，无法作为软件运行的 single source of truth。

抛开这个终极图景的判断，我在日常实践中，也比较反对写非常详细的 spec 给 agent 使用，尤其是全人工撰写。

主要原因是：软件开发一定程度上是个探索发现过程，对于有一定复杂度的系统和需求，我们是无法在一开始就给出完美的 spec 的。而且即使写了，里面可能也有冲突，模型在遵循上可能也有问题。要写出详尽的 spec，一定程度上等同于把代码实现写出来了。

来自 Kiro blog

个人在实践中，有几次给了 agent 相对模糊的一个方向和验收的 high-level 标准，然后发现 agent 实现出来的方案非常的优雅，相比我一开始脑海中的思路来说明显更优。有点像著名的 AlphaGo 的第 37 手，让我深深感受到没有因为太过详细的 spec 而限制了它的发挥空间。

当然很多时候，探索和计划步骤还是很有必要的。我目前的实践是从自己的 review 诉求来倒推：

结合上一项原则，generation is cheap，我们也完全可以同时尝试几种路径，比如一个 session 直接做需求，另一个 session 让 agent 产出 spec 之后再工作，选择效果更好的即可。当然总体来说，我们仍然是 bias to action。

“复利工程”

前两个原则总结一下，就是让 agent 能更加自由地做多次尝试，发挥出 agent 的能力上限。但我们的实践思考显然不会止步于此。如何能让 agent 每次的尝试下限更高，更有可能产出符合预期的结果？这就引入了所谓的“复利工程”。

这里核心的实践就是形成一套 agent 的“长期记忆系统”，其实就是我们耳熟能详的AGENTS.md，skills 等。

Claude Code 和 Codex 等产品都可以通过/init命令来让 agent 自己阅读探索代码库，形成初版的文档。不过我感觉它们写的基本都有点啰嗦，实际上可以更精简一些，主要记录你项目“特殊”的部分，而不需要重复软件工程的通识。如 Cursor blog 上的示例：

Cursor blog 上的示例

接下来就是“复利”的部分，如果一个类似的错误 agent 犯了 2 次以上，可以考虑记录到AGENTS.md中。

也可以让 agent 自己总结最近的对话 session（例如~/.codex/sessions目录），将用户反馈、agent rollout 过程中走的弯路等后续可复用的知识，记录到AGENTS.md中。

由于AGENTS.md相当于一个内置的全局记忆，因此我们也需要控制它的长度，避免 session 一开始，agent 的注意力已经开始涣散了。

当你逐渐熟悉 agent 的工作习性，你会发现更多可以提升其工作效率的地方。比如一个感觉上不那么复杂的任务，agent 却花了很长时间来完成，就可以深入分析一下它的工作过程，来总结一些可以复用的经验。

Context 意识

在与 agent 协作过程中，控制 context 的意识非常重要，前面已经提到一些，这里简单总结一下：

这里也顺带一提一些 coding agent 产品应对复杂、长程任务带来的 context 压力的方案：

利用文件系统来 share context

第二阶段：并行工作

做到代码 100%由 AI 生成之后，很现实的一个问题是，当 AI 在工作时，我们干啥？OpenClaw 作者的分享 给了我们很好的回答：应该并行安排 agent 开发。

好吧，其实也是很自然的一个想法，并不是他的独创。包括早先推出的 Antigravity，也早就用 Agent Manager 的产品形态让我们得以窥探未来程序员的工作形态。

目前我最喜欢的产品是最近推出的 Codex App，可以直接以多个文件夹的组织形式来管理本地 agent 的并行任务。当然也包括他们很早就支持的云端任务并行。

Codex App 的多 project 并行管理

在本地并行工作时，我的方法非常的简单淳朴，就是 clone N 个一模一样的 git 项目文件夹，然后提前把环境 setup 好。省去了用git worktree每次还要安装依赖之类的麻烦。

目前我的并发度也不高，大概同时做 5 个左右任务，直接在 Codex App 中切换文件夹，（语音）输入 prompt 即可。这些任务的组成大致如下：

Codex 中可以很方便地看到每个任务的运行状态，哪些等待 approve 或 review 结果。OpenClaw 的作者说就像玩星际一样在各个基地之间来回切换……

对于云端并行来说，因为每次需要启动一个无状态的沙箱环境，因此需要多轮交互沟通的任务目前做起来并不太合适。个人比较喜欢安排一些 agent 完成比较好、低风险、小 scope 的任务，比如补充测试、代码重构、明确的 bugfix 等。当然随着 agent 的进步，也可以时不时给一些复杂任务测试一下。

随时给云端 agent 派一些固定任务

由于 agent 能力的通用性和对 context 完整性的诉求，我认为这种在一个产品中并行分派任务的形式，才是更加 AI native 的“多 agent”工作形态。而不是很多人想象的那种采购多个 agent 产品来指挥多个 agent 干活。

如果是基于一个传统产品的界面，在旁边增加一个 chat 侧边栏，本质上还是单任务+串行工作的方式，效率提升有限。只有利用好 agent 能够在后台默默工作、自我闭环的特性，才能最大发挥 token usage 转化为工作产出的效率，而不受限于人类有限的注意力。

Context Switch

切换到这种并行工作方式之后，很快会意识到目前最大的瓶颈是人类注意力和任务切换的极限。每个任务分给人类大脑的专注时间最好要大于 10 分钟，太频繁的 context switch 很影响效率和精力。一般我分配的专注任务包括：

这里最最关键的核心是如何让 agent 能够尽可能地自我闭环一个任务，并不断扩大这个任务的 scope，从而减少人类干预的频率。

比如一开始可能碰到的情况是 agent 经常停下来需要我们回答一些问题，或者任务做了一部分就自动终止了（“接下来我可以帮你实现……”），于是就有人开发了类似 Ralph loop 这样的工具来提升 agent 的自主性。顺带一提，Codex 好像这方面的问题比较少，所以我也并没有使用 Ralph。

然后可能会发现 agent 在工作过程中缺少一些我们日常工作的 context 信息，如内部软件包的文档、线上日志、数据库访问、tracing 系统内容获取、bug report、feature PRD 获取等。我们可以审视每次需要人肉提供 context 的环节，逐渐优化提供给 agent 的 tools/skills。

在扩大 agent 可以自闭环任务的 scope 时，也是类似思路。比如最基础的，如果我们没有提供给 agent 跑 lint，unit test 的工具，那么它的任务范围就很难超出“完成代码编辑”。而 agent 如果可以自己跑浏览器验证前端交互，或者发布到测试环境跑集成测试，验证 API 的正确性，那么它可自闭环的任务范围就能大大扩展。

在第一阶段我们提的 100%由 AI 生成代码，已经显得有些狭隘，我们的视角需要转向 SDLC 的各个环节，看能否由 agent 来 100%闭环。

当然即使各环节都做得比较完善了，仍然会有绕不过去的一环，就是最终的 review 与验收。

Review 与验收

有意思的是，AI 写的代码，到底要不要 review，也是个有争议的话题。

我目前的观点是，对于需要长期维护的大型项目，通过 review 来控制项目复杂度，并确保我们的 agent 并行开发的效率得以持续，是必不可少的。我愿称之为 vibe engineering 而不是 vibe coding。

从实践上来说，我也从早期的每行代码都看，逐渐演化到了与 AI 一起 review，各有侧重的模式，逐渐优化了这个环节的瓶颈问题。目前我让 AI 做 review 时会使用如下的 prompt 模板：

我想请你和我一起进行 code review。

首先请执行`glab mr checkout $MR_ID`命令，切换到对应的代码分支，并确保内容是最新的。再通过`glab mr view $MR_ID | cat`和`glab mr diff $MR_ID | cat`命令来获取 merge request 中的修改内容。

然后，请开始*一步一步*深入思考，仔细执行如下的 code review 流程。如果改动比较简单直接，你也可以自行选择跳过某些步骤。

1. **理解业务目标**：判断你是否能理解这个改动的业务目标。
2. **High-level review**：查看当前的项目内容，本次改动是否放在了合适的位置，是否尽可能复用已有实现。是否有破坏了现有设计与逻辑的可能？
3. **检查 Bug**：仔细分析当前的代码修改，是否隐含了业务错误、逻辑纰漏或安全问题？对于“没有修改”的相关联部分代码，也需要检查是否有遗漏。
4. **代码清晰度**: 评估代码设计，逻辑是否简洁易懂，命名是否清晰且合理，假设一年后再来读这几行代码，是否能轻松理解？
5. **KISS 原则**：审视每一行代码是否简洁、清晰，没有不必要的复杂度，尤其避免重复造轮子。检查是否有没用到的定义，过于复杂的逻辑，过多参数等问题。
6. **单一职责**：是否做到了每个函数/类只做一件事，职责明确，项目结构清晰。注意控制文件/类/方法的代码行数。
7. **测试覆盖**：复杂业务逻辑必须有相应测试。但也不应该过度测试，例如对于没有 if/else/for 等控制逻辑的代码，不需要写测试。一般来说只对 public 方法写测试。

完成整个流程后，请对 code review 中发现的重点问题进行总结，以中文输出。

需要注意 agent 做 review 时并不是只看 diff 的，而是会跟人类一样结合代码库探索来做整体评估。

AI review 效果示例

当然你也可以根据自己的项目特点和技术偏好来调整这个 prompt 模板，尤其是你自己在 review AI 的代码时经常注意的一些维度。

有时候 agent 在 review 时会给出一些“假阳性”的反馈，这时候的处理方式也与之前让 agent 写代码类似。如果是因为 agent 缺少一些具体的 context 信息，我通常会通过补充到代码 comments，或者优化函数与变量命名的方式，来让 agent 更好地理解。如果是更加通用性的知识，一般会优化AGENTS.md文件中的信息。

在使用这个 prompt 模板过程中，可以持续观察 AI review 中很少反馈问题的维度，以及跟人类 review 反馈差异最大的领域，这可能是人类需要重点 review 的点。

以我半年多来使用这个模板的经验来看：

所以目前我的策略是，代码细节问题的 review 基本上可以放心交给 AI 来做（除非是非常 out of distribution 的场景），而业务对齐、架构设计等宏观问题的 review 则需要人类来把关。我猜测模型在训练过程中，对于这种架构合理性的 reward 反馈是比较少的，并没有得到充分的训练。而找 bug 这种相对明确、反馈及时的 reward，模型则得到了充分的训练。

这里的“架构”是个相对广泛的指称，包括与业务结合的很多设计。比如根据业务做合适的领域建模，因为业务上还未发布所以不需要考虑兼容性等决策。

另外我们在项目中，也尽量把所谓的架构合理性、技术债等概念，通过各种工具的检查与分析来形成显性的反馈提供给 agent，而不仅仅是通过 prompt 来触发 review。比如：

从长远来看，随着更多项目切换到由 agent 来进行开发，我们应该能针对性地收集到类似“项目维护成本”这样的 reward 信号，进而提升 LLM 的架构感知能力。

但我们也知道，很多 high-level 的技术决策背景是复杂的，与战略、业务、组织等紧密耦合。例如我们是否要迁移到微服务架构，可能与业务本身所处的阶段和价值，组织架构设计，团队成员的技术积累（即使有 agent 的帮助），技术世界的演进等等方面相关。这种稀疏、信息不完全、归因模糊、反馈周期长、不可重复的决策，可能在相当长一段时间内都难以完全由 agent 来自主完成，而更多是 agent 给出候选方案，分析 trade-off，由人类做最终决策的形态。

测试与护栏

发布之前除了 review，验收的很大一部分需要依赖测试。而发布之后的各类工程护栏也显得愈发重要。

核心问题是：如何让 agent 提交的代码，能在一个完善的保障体系下被持续地、安全地合并进 main，其中包括：

静态代码检查需要重视和完善

这里也是同样观察人工工作占比大的地方，逐渐优化。比如我们在跑通 lint，test，完成 review 后会合并主干分支，后续的集成测试验证往往需要人工操作或者触发。于是我们告诉 agent，当代码合并后，会自动部署到集成测试环境，可以让 agent 自行验证 API 是否正常工作，以及后续可以自行维护和执行自动化集成测试。

工作变化

自从养成了让 agent 并行工作的习惯，我的一些工作方式也逐渐开始发生变化。比如之前接到需求，我习惯于建一个 Jira backlog task 记录一下。现在一方面任务的吞吐量大大提升了，另一方面也觉得，反正后面还要从 Jira 里捞出来放到 Codex 里，为什么我不立刻就 prompt 一下直接开启这个任务呢？

甚至 backlog/tasks 本身也可以考虑用一个文件夹的形式放在项目库里，基于 git 来做项目管理。后续可以搞个 proactive agent，不断地扫描还未完成的任务，自动捞出来做。

还有像 Vibe Kanban 这类产品，一定程度上也是淡化原先的项目管理，释放并发 agent 工作的生产力。

另外为了进一步提高生产效率，甚至可以考虑在测试相对完备的情况下，直接基于 main 分支开发和提交，省去 feature branch 的切换。

虽然 agent 自己解决代码合并冲突的能力也足够强了，但总体来说我们还是需要有更多架构设计的考量，降低模块耦合还是能有效提高 agent 并行工作的效率和稳定性。

第三阶段：组织变革

延续上面说的工作习惯改变，我们已经可以看出一些传统工作流程与组织方式也需要很大的变革。

比如之前的工作方式中，一般是产品经理去收集和理解需求，然后写成 PRD 交给开发去实现。但是产品对于技术实现细节并不了解，所以几乎不可避免在开发过程中出现没有明确定义或者逻辑有冲突的地方。这时候又需要重新拉会讨论，修改或完善 PRD。在这个过程中，所谓的“alignment”往往是非常耗时耗力的，毕竟无论是 PRD 还是代码，都是不同角色工作的心血，难免会有一些 ego 在里面，不愿意轻易做出改变。

再比如研发环节之前也往往会区分前端、后端、测试、运维等不同角色，当后端完成 API 接口设计后，需要与前端去同步相关内容，然后等待前端排期完成相应部分的开发，才能进入联调。后续再进入到测试、部署发布等环节。这里每一个环节的交接，都存在着信息完整性、双方理解的一致性以及工作排期等诸多问题。

如果某些岗位的角色率先通过并行 agent 的方式大大提升了效率，上述的很多效率上的冲突，甚至会变得更加显著。而让多个角色都通过并行 agent 的方式来工作，但继续保留这个前后依赖的流程，又好像没有必要，毕竟人与人之间的 alignment 带宽并没有变化。

或许我们可以让一个人带领 agent 完成全栈的开发测试运维工作，不再需要多个角色之间的流程依赖和沟通交接。或许我们可以让一个人闭环从产品需求到开发上线，过程中如果有想法的变化调整，也都是“自己推翻自己”，难度大大降低。

甚至推广一下，不仅仅是产品研发领域。比如之前的组织形式中，销售负责商机判断与客户信任建立，售前负责需求挖掘与方案匹配，实施负责项目交付与落地推进，技术支持负责问题响应与根因排查。每一次交接，同样面临信息完整性、理解一致性和排期依赖等问题。或许未来一个客户经理带领 agent，就能闭环从线索跟进、方案输出、项目交付到售后支持的全流程——客户问题不再在不同角色之间流转和衰减，而是在一个统一的上下文中被持续跟进和解决。

跟着这个思路去设想，未来人类员工之间的分工边界会是什么？当 agent 承接了大部分执行工作之后，人类角色的边界就从“我能做什么”转移到了“我能判断什么”。一个人能够闭环的 scope 上限，就是他全链路 review 能力的边界。这件事情的发生，或许相比 agent 产品技术本身的变革来说，需要更多的时间。

推广 AI Coding

前面提到的组织变革设想可能对很多人来说感觉还有些“遥远”，眼下大家更关心的可能是如何在公司内部推广 AI coding，将更多员工的生产力推向第二阶段。

除了常规的给员工报销 AI 产品费用，组织分享培训外，个人感觉比较有效果的一些方式还包括：

程序员的发展方向

还有很多人会担忧程序员这个职业的未来发展方向。从前面的叙述可以看出，我们未来的工作重心可能会转向以下一些方向：

看起来的确很多传统的程序员技能重要程度都在快速降低，我们甚至都不太需要“初级程序员”了。但另一方面，对于技术和架构方面的品味和判断力，又要求程序员积累大量的实战经验才能培养出来，这看似是一种不可解的矛盾。

不过乐观一点想，在 agent 的帮助下，我们做项目的速度大大加快了，那么所谓的经验积累是不是也能得到加速？另外借助 AI 来做基于实战的学习也变得前所未有的高效。所以只要对于软件的诉求在不断增长，相信程序员这个职业仍然能得到很好的发展。

Mindset 总结

最后总结一下文中讨论到的一些重要的 mindset：