2023 年的时候，@gneubig 曾经让我读过 Steve Hicks 在 2021 年写的这篇工程博客，讲的是如何写 Small, Focused Pull Requests。到了 2026 年，再重新读这篇文章，觉得其中的工程准则比以前更加珍贵。 这篇文章讲了一个在今天 AI 生成代码的时代特别容易被忽略的区别：small 不等于 focused。五个互不相关的改动，即使总共只有几十行，也可能是一个很糟糕的 PR；一个完整的 feature 即使目标非常明确，如果改动范围太大，也可能根本没有办法被认真 review。真正好的工程实践，是把代码组织成一个其他工程师能够理解、验证，并且愿意对其负责的变更单元。 文章给出了很多非常实际的方法：先搭建能够运行的 walking skeleton，再逐渐完善功能；把 infrastructure change 和 feature implementation 分开；把有争议的架构决策与常规实现隔离；尽量增量集成，而不是等一个巨大功能全部完成之后，再一次性提交一个庞大的 PR。 我觉得 AI coding 让这些原则变得更加重要了。我们已经极大降低了代码生成的成本，但并没有同等程度地降低理解代码的成本。Agent 可以在一个下午生成几千行看起来相当合理的代码，但这不代表 human reviewer 就突然获得了在同样时间里认真理解几千行变更的能力。 更麻烦的是，如果一个巨大的 AI-generated PR 同时混合了 refactoring、架构设计、性能优化和新功能，即使测试全部通过，我们仍然很难判断其中哪些假设需要特别谨慎地审查。最终，我们只是把原本开发者需要承担的认知成本，转移给了 reviewer 和未来的 maintainer。 我非常喜欢（至少似乎不得不用） coding agent，也完全不想回到（其实我还挺想回到的，但不能只是我一个人回到）每一行代码都必须亲手写的时代。但我一直强调，AI-assisted software engineering 并不只是如何生成更多代码，而是如何把这些代码组织成能够被人类真正理解、验证和维护的变更。 Small, focused PR 不是一种过时的工程仪式，而是避免开发速度最终演变成 review debt 的重要手段。 我自己的工程启蒙很大一部分来自 Graham。我从他那里学到的远远不只是科研。他大概是最早教会我应该怎样严肃地思考软件工程的人。非常感谢 @gneubig @vijaytarian artsy.github.io/blog/2021/03…

为什么这么说我？为了软件高质量，我用自己的钱来订阅全世界最好的最贵的且最难订阅的模型 7×24 小时去实现和满足每个用户的真实需求，而且是个完全免费的软件，怎么就在你的口中成了「快餐式服务」和「这种作者」了？看着你挂着 newapi 的官方 logo ，很颠覆 newapi 在我心中的形象，希望你积点口德。

LightOS，国庆节，任何地方都可以行走编程

之前给自己写的plan 工具也是类似的思路 普通plan mode 的可读性已经支撑不住复杂任务了，sdd 则是压根没法看信息爆炸 所以照着 需求，用例， 确认， uiux， 可行性， 建模， tech design， 任务，验收 的方式来管理， 每个部分采用不同的schema 来维护，比如 任务就是 tree nides， ux 是html