直到今天，我依然很难相信自己已经几乎不再亲手写代码了。更准确地说，我难以相信自己过去竟然长期依靠手写代码工作。软件开发这件事已经发生了根本性的变化，而过去那些被我们视为理所当然的工程价值观，究竟还有哪些依然重要，也成了我近来反复思考的问题。
在开始讨论之前，为了避免有人质疑我只是纸上谈兵、没有真正交付过东西，我先列举一下过去几个月里自己参与的项目：
- Vite+：为产品发布编写 Rust 功能模块——虽然我其实根本不会 Rust，其中约 90% 的代码由 AI 完成；
- fate 1.0：增加 Live View、drizzle 与 GraphQL 支持、Vite 插件以及垃圾回收功能，全部由 AI 编写；
- Codiff：一个快速、极简且美观的 Diff Review 工具，全部由 AI 编写；
- Athena Crisis：新增功能并修复超过 70 个缺陷，全部由 AI 编写；
- Void：一个尚未发布的 Metaframework 与云平台项目，全部由 AI 编写。
经过这一阶段的实践，我越来越确信一件事：如今的编码 agent 所写出的代码质量，已经与我自己编写的代码相当，很多时候甚至更好；而过去需要数周才能完成的工作，它们往往几分钟就能交付。既然写代码本身不再是主要瓶颈，那么许多原本根本不会开始的项目，现在也终于有机会被完成。
这些项目大多是公开的，任何人都可以直接查看代码验证我的说法。我并不是在炫耀什么，而是真切地感到震惊。在我的职业生涯里，从未出现过如此巨大的开发体验跃迁——一种工具不仅让开发速度成倍提升，同时还能提高最终交付的软件质量。
以 Athena Crisis 为例。这是一个诞生于 AI 时代之前的项目，最初完全由我手工编写。后来因为一直抽不出时间维护，我干脆让 Codex 持续循环执行“发现问题—修复问题”的流程。最终它修复了七十多个 Bug，增加了新功能，补充了测试，而完成这些工作的同时，我甚至还能在别的项目里等待其他 agent 的执行结果。结果是，Athena Crisis 现在比过去任何时候都更快、更稳定、功能也更丰富。除此之外，它还顺手优化了 CI 流程，改进了 Steam 上传流水线，为一些复杂的多人交互场景补齐了测试，甚至还帮我开发了一个专门用于比较两百多个像素图标版本差异的小工具，从而彻底更新了游戏的视觉风格。如果没有编码 agent，这些事情根本不会发生。
我现在如何使用 LLM
回头看一年前的工作方式，变化已经非常明显。
那时候我几乎不在本地运行模型，通常会把上下文严格限制在某个模块或函数范围内，并且为同一个问题生成多个候选方案进行比较。
而现在，我几乎完全依赖 Codex CLI，并搭配 GPT 5.5 high 模式。只要代码库本身拥有足够完善的约束和护栏，模型通常能够在一次尝试中直接给出正确方案，甚至不需要复杂的提示词设计或者精细的任务拆解。我发现推理等级过低会明显影响代码质量，而 xhigh 模式则往往过于缓慢，并且喜欢把简单问题复杂化。过去一段时间里我试过很多模型，但无论从速度、正确率还是协作体验来看，目前都没有哪个产品能够与 Codex 相提并论。
很多人喜欢同时在同一个项目中开启多个 agent 会话，借助 worktree、代码副本或者其他方式并行开发，但我发现自己在这种模式下效率并不高。因为我仍然坚持阅读所有代码，而在同一个项目里同时处理多个互不相关的改动，会让我频繁切换思维上下文，反而拖慢速度。
相比之下，我更喜欢在不同项目之间切换。
通常我的桌面会同时打开多个 Ghostty 窗口，每个项目占据一个窗口，左边是 Codex，右边是终端。借助这种方式，我能够同时推进三到六个项目，而真正的瓶颈往往不再是代码实现，而是方案讨论与代码审查。
这种工作方式甚至改变了我对工作环境的偏好。
过去我非常喜欢只带一台笔记本随处办公，但现在我越来越依赖大屏幕。因为同时管理多个项目之后，空间本身开始成为一种认知工具。我会不自觉地把不同项目固定在屏幕上的特定区域：fate 总是在中上方，Void 往往位于左侧，而 Athena Crisis 则固定在右边。奇怪的是，这种空间映射似乎真的能够帮助大脑更有效地切换任务。
至于提示词，我其实相当懒。
面对一个新项目时，我通常只是开启一个新会话，然后直接告诉模型：
我想做 X，请从 Y 和 Z 获取上下文，先给出方案设计，然后把需要向我确认的问题列出来。
随后我会通过对话不断修改方案，直到满意为止，最后再让 agent 开始执行。
修复 Bug 时，我采用另一套流程：先给出复现方式和背景信息，并强制要求模型首先写出一个失败测试。这样做能够显著提高它修复正确问题的概率。否则模型经常会出现一种很典型的现象——它修复了错误的问题，采用了错误的修复方式，甚至写出了验证错误行为的测试。
尽管模型能力已经远超从前，但让它们保持在严格约束之下，依然是获得优秀结果最可靠的方法。它们仍然会跑偏，也仍然会犯大量错误。有时候与其继续补救，不如直接终止会话重新开始。
对于规模较大或者复杂度较高的改动，我通常会运行数轮 /review，分别从不同角度检查实现质量、缺陷风险以及与原始设计的一致性。功能验证完成之后，我会使用 Codiff 审查代码变更，经常只需要执行 codiff -w，让 Codex 自动生成一份未提交代码的 Walkthrough。
有时候，我甚至会发布自己没有逐行认真阅读的代码。
如果测试足够完善、整体结构合理，而且改动位于风险较低且容易回滚的区域，我会接受这种做法。事实上，如今 agent 所犯的错误类型已经与过去人类工程师常犯的错误明显不同。某种程度上，我甚至会对手写代码保持更高的警惕，而对 agent 生成的代码给予更多信任。
理想情况下，完成验证之后最好的下一步就是直接推送到主分支。
遗憾的是，大多数团队并不是这样运作的。一旦进入 PR、评审和协作流程，LLM 带来的大量速度优势就会迅速被消耗掉。因此我越来越相信，如果技术组织希望在未来保持竞争力，就必须重新审视现有协作模式，主动拆除那些阻碍事情落地的组织性障碍。
现代工程价值观
过去很长一段时间里，我一直在思考：对于 2026 年以及更远的未来而言，究竟哪些工程原则仍然值得坚持？哪些价值观能够真正帮助个人与组织提升速度？
回顾自己的工作流，我会产生一种非常矛盾的感觉。
一方面，几乎所有事情都变了。
另一方面，真正重要的东西似乎又没有改变那么多。
我常常思考个人开发者与大型科技公司之间的区别。许多今天由小团队搭建的基础设施，本质上和大型科技公司多年前就已经拥有的体系并没有太大差别。有时候人们批评 agent 生成大量垃圾代码，我总会觉得有些好笑——他们大概从来没有见过大型科技公司工程师制造的垃圾代码。还有人质疑：“如果你不理解代码，怎么可能高效工作？”但现实是，在大型组织里，大部分人本来也只理解极少一部分代码。
我并不认为编程或者代码会消失。
那些用 Markdown 写成、充满歧义的英文 Spec，并不是一种好的编程语言。相比之下，利用 agent 与动态代码协同工作的方式显然合理得多。工程工作正在从“亲自编写代码”逐渐转变为“指挥生成代码的系统”。很多人想象中的未来其实并不会出现，工程世界最终仍会比他们预期得更接近今天。
那么，在这样的时代里，究竟什么样的价值观能够帮助我们保持高效率？
无论执行者是人还是 AI，我认为答案都大同小异。
强烈的主人翁意识
最优秀的工程师始终拥有强烈的 Ownership，以及对所负责领域深入的理解。
Agent 并不会削弱这种特质，反而会放大它。
一个真正理解产品的人，现在能够以前所未有的速度推动事情前进；而一个缺乏背景知识的人，则能够以前所未有的速度制造噪音。随着这种变化发生，组织协调本身反而会变得更加昂贵。未来最有效率的团队，很可能是只有两三个人的小团队，拥有清晰的责任边界和相互隔离的代码仓库。
Ownership 不只是负责实现功能，而是要理解系统架构、产品需求、各种权衡以及长期方向，并能够审查 agent 产生的工作成果，在必要时直接做出决策，甚至直接向主分支提交代码。
对于这种规模的小团队而言，Code Review 的意义不再是争论代码细节，而是确认彼此是否达成共识。只有当仍存在尚未讨论清楚的问题时，Review 才真正有存在价值。
品味，品味，还是品味
我对于废话的容忍度极低。
而在 agent 时代，每个人都能够轻而易举地产生海量废话。
请停止这样做。
品味的重要性不仅体现在能否打造优秀产品，更体现在你是否知道什么事情值得投入时间。相比不断追求更高的产出速度，我更希望工程团队花更多时间思考：
什么值得做。
因为这个问题的重要性已经远远超过“怎么做”。