资深工程师应亲自跑通 AI 编码代理

在 AI 编码代理快速渗透工程团队的当下，一种声音认为技术领导者应当身体力行、主动产出大量「AI 痕迹」——即消耗的 token、生成的代码、失败的原型与被废弃的分支——以便在尚未形成共识的领域中建立第一手判断。这篇文章来自一位资深工程师的观点讨论，核心论点是：单纯用 token 消耗或代码行数衡量工程师贡献是错误的，但资深工程师刻意回避 AI 编码工具同样不可取。

历史模式与新的拐点

作者援引 Andy Grove 在《High Output Management》中提出的杠杆概念：领导者的产出不仅来自自身直接工作，还来自其赋能他人完成的事情。传统上，工程师越资深，越被期望通过评审、协作、辅导等间接方式创造价值，直接产出的代码反而减少。

但 AI 改变了这一前提。代码生成、智能体协作、上下文管理等领域仍在被反复重写，不存在稳定范式。资深工程师若长期远离写代码这一生产环节，便无法对新的生产工具形成有效判断。

尚未达成共识的关键问题

作者列出一系列仍在探索中的开放问题，包括：

• 代码评审：是否应通读所有代码？是否只审查测试与行为？是否可依赖 AI 解释变更？是否需要多重评审关卡？
• 上下文管理：AGENTS.md 应包含什么？有效上下文窗口是多少？智能体是否应自主调用技能？
• 代码库层面：LLM 是否应维护代码库 wiki？Markdown 计划是否应入库？代码库的整理与组织是否仍然重要？
• 自主性：应将智能体作为副驾驶还是让其独立运行？是否采用 spec-driven development？智能体是否应拥有独立身份？是否应连接 GitHub、Jira 等外部服务？

围绕这些问题，新的工具类型正不断涌现：终端与多路复用器、Agent GUI、diff 与产物查看器、编排器、任务管理器、沙箱、pre-tool-use 钩子、凭据保险库等。作者认为，这些问题无法靠推理工程原则回答，必须在真实代码库上跑通代理、主动制造失败才能得出结论。

来自实践的初步结论

作者分享了亲身实验后形成的若干判断：

• 上下文窗口：即便是 Fable、Sol 等较先进的模型，在长上下文下仍会大量出错并忽略指令。作者据此认为存在一个「有效上下文窗口」，且会随任务变化；他目前将窗口控制在 50% 以内，并在超过 20% 时触发警告。
• 自主性：模型现在高度 agentic，会主动开 PR、推主线，甚至自作主张添加未被要求的功能。指令越模糊，这种情况越严重。作者在一次清空技能栈与 AGENTS.md、放弃自研 SDD 框架后，正在重建带指令护栏与确定性钩子的 harness，强调任务前置界定可以减少意外。
• 代码评审：人工评审仍有重要价值。智能体在规格或指令未明示的决策点上会自行「填空」，常导致过度设计、多余测试甚至质量低下的代码，且往往不会主动报告。

文章最后表达的核心观点是：技术领导者有责任带着团队一起试错，亲自跑代理、推模型、搭工具栈，并为新的工作方式建立标准，否则难以在快速变化的 AI 生产关系中保持影响力。