个人网页

Specification 写好了。AI 知道改哪里、怎么改、不能动什么、需要测什么。接下来就是把这份精确的描述，变成可运行的代码 这就是 Execution。在整个链路中： 12Knowledge → Context → Decision → Specification → Execution 收集 筛选 判断 翻译 执行 它是最后一环——前面五环的全部投入，在这一环兑现 但 Execution 有一个独特之处：它是整个链路中 AI 最擅长的一环，却也是整个链路中最依赖上游质量的一环 如果 Specification 准确完整，Execution 是高效的、机械的、几乎不需要人工干预的。如果 Specification 有遗漏或歧义，AI 会忠实地把问题变成 bug。如果 Specification 约束过多，AI 被捆住手脚，发挥不出它在实现细节上的优势 Execution 的上限，是 Specification 的质量。而 Specification 的上限，是 Decision 的质量。以此类推。整个链路是一条质...

上一篇文章讨论了 Decision——在信息不完整的情况下，如何做出最好的工程决策。 但决策做出来之后，问题还没完。决策是在人脑子里完成的——带着判断、权衡、以及对系统上下文的理解。而下一环 Execution，是由 AI 来执行的——AI 需要精确、完整、无歧义的输入 人脑子里的决策，和 AI 需要的输入，是两种不同的东西。二者之间存在一个翻译鸿沟 在整个链路中： 12Knowledge → Context → Decision → Specification → Execution 收集 筛选 判断 翻译 执行 Specification 就是这个翻译层。它回答的问题是：如何把工程决策，变成 AI 可以精确执行、不会误解的描述？ 先划清边界：这不是什么 在讨论 Specification 是什么之前，有必要先说明它不是什么。因为「Specification」这个词在软件开发里有很重的历史包袱，容易被理解成已有的概念 不是需求文档。 需求文档（PRD，产品需求文档；SRS，软件需求规格说明）描述的是「系统应该做什么...

经过了上一篇关于 Context 的讨论，一个自然的问题是：上下文构建完成之后呢？ 上一篇文章的结论是，Context 构建永远不可能完美——五重约束互相冲突，完备性和最小性无法兼得。这意味着一个让人不太舒服的现实：工程决策，永远是在信息不完整的情况下做的 这听起来是个缺陷。但这正是「工程判断力」之所以存在的原因。如果每次决策之前信息都是完备的，那就不需要判断力了——按规则执行就行 在整个 AI Native 软件开发的链路中： 1Knowledge → Context → Decision → Specification → Execution Decision 是第三环。它是整个链路的价值兑现点——前面收集 Knowledge、构建 Context，全部是为了支撑这一环。如果 Decision 的判断质量低，上游的一切投入都白费了 更重要的是，Decision 可能是整个链路中最需要人的一环 四种决策 回到第一篇里提过的四个核心问题。它们其实对应了四种不同类型的工程决策： 1234改哪里 → Location Decision （定位决策）怎么改 → Appr...

上一篇文章把软件开发中的知识拆成了六个层次：代码、业务逻辑、架构设计、历史决策、需求、基础知识 拆完之后，一个很自然的问题就摆在了面前：六层知识浩瀚如海，但一次具体的开发任务——比如「在退款流程里加一个超 30 天拒退的校验」——只需要其中的极少一部分。剩下的全是噪音，不仅没用，还会干扰判断 怎么从知识的海洋中，捞出刚好需要的那一滴？ 这就是 Context 要解决的问题。在整个 AI Native 软件开发的链路中： 1Knowledge → Context → Decision → Specification → Execution Context 是第二环，承接 Knowledge，支撑 Decision。但我越来越觉得，它可能是整个链路中最难的一环 不是因为其他环节简单，而是因为这一环要解决的问题，本质上没有一个完美解 一个看似简单的问题 先别急着讨论理论。回到上一篇那个退款场景： 任务：在退款流程中增加一个校验——超过 30 天的订单不支持退款。 这个需求只有一句话。但为了正确地实现它，你需要知道： 退款的主流程在哪里？（代码） 退款之后有哪些异步链路——MQ...

上一篇文章讨论了一个观点：软件开发真正管理的对象，也许从来都不是代码，而是知识。AI 的出现没有让知识变重要——它只是让我们不得不正视这个一直存在的事实 但文章写完之后，一个更基础的问题一直在我脑子里转： 当我们说「知识」的时候，到底在指什么？ 代码算知识吗？业务逻辑呢？架构设计呢？那些只存在于老员工脑子里的历史决策呢？这些看起来完全不相关的东西，为什么都叫「知识」？ 这篇文章把这个问题拆开来看 一个更完整的视角 在进入正题之前，我想先给出一个整体框架。这其实是我后续一系列思考的基础： 我认为 AI Native 软件开发的核心链路是这样的： 1Knowledge → Context → Decision → Specification → Execution 每一环回答一个不同的问题： 环节 核心问题 产出 Knowledge 系统中存在哪些信息？ 全部知识空间 Context 当前任务需要哪些信息？ 完备且最小的信息子集 Decision 基于这些信息，做什么选择？ 工程决策 Specification 决策如何转化为可执行的描述？ 精确的变更规格...

最近一段时间，一个感受变得非常清晰：AI 写代码的速度，已经远超过去了 一个 CRUD 接口、一个 Controller、一个 SQL，甚至一整个功能模块，AI 都能够很快完成 但是，在真正的业务项目里，我花费时间最多的，却越来越不是写代码 而是： 不知道应该改哪里； 不知道为什么这里要这样设计； 不知道有没有类似实现； 不知道修改之后会影响哪些地方； 不知道这个看起来无关的模块为什么会一起坏掉。 举一个很常见的例子，一个需求只是：修改退款流程中的某一个逻辑。看起来只是改一个 Service，结果上线测试之后，却发现： 积分没有发放； 优惠券状态异常； 消息通知没有发送。 最后检查代码才发现：退款流程后面还有 MQ Event 定时任务 另外几个系统的监听逻辑 这些依赖关系，并没有直接写在你修改的代码里 困难的地方，从来都不是：怎么写代码，而是：如何理解这个系统 复杂性的真正来源 前段时间重新阅读 John Ousterhout 的《A Philosophy of Software Design》时，有一个观点让我印象很深，作者认为： 软件真正的复杂性，并不来自代...

最近几个月，我开始越来越多地使用 AI 参与日常开发，起初我以为变化最大的会是 Coding 但真正用了一段时间后，我发现最大的变化其实发生在研发流程——一个我们过去习以为常、现在却开始处处「别扭」的地方 一、旧流程为什么开始别扭 一个让我一直觉得别扭的问题 我们团队的研发流程和大多数技术团队差不多： 1需求评审 -> 技术方案设计 -> 技术方案评审 -> 开发 -> 测试 -> 上线 过去，这套流程跑得很顺，但在引入 AI 之后，我们很自然地开始让 AI 根据需求直接生成 Spec（实现规范）进行开发。这时不出意外的话，很快就遇到了一个尴尬的情况～ 就是 AI 生成的 Spec 非常的详细，详细到了包含 DTO、数据库字段、SQL、Mapper、API、Migration、Unit Test，甚至每个字段的命名和类型 这时候，当我们拿着这份 Spec 去评审时，就会有些奇怪…，因为评审会上，大家真正关心的问题是： 整体业务流程是否合理？ 服务之间如何交互？ 数据应该归属于哪个系统？ 为什么用 MQ 而不是 RPC？ 为什么新增一张表，而不是...

我们开发的每一个需求，基本 80% 的时间在搞清楚该改什么，只有 20% 在写代码。这不是能力原因，更是在于软件的复杂度 一个似曾相识的场景 比如接到需求：结算单状态机增加一个「部分退款」中间状态 在梳理了 SettlementService、SettlementController、SettlementStateMachine 后，改动范围很清楚——加一个枚举值，改三条状态流转路径。改动量很小，代码 review 也顺利通过。 结果上线第二天，告警来了：对账报表里部分退款的结算单被重复计入 问题出在一个没人知道的类——ReconciliationReportBuilder。它内部有一个 switch-case 遍历结算单状态来决定归入哪个科目，新增的枚举值走到了 default 分支，被当成「已结算」处理了 这个类的存在，在改代码的时候可能完全不知道。甚至不知道「我应该知道它的存在」 如果你在接手业务需求的时候也踩过类似的坑，这篇文章就是写给你的 复杂度不是代码行数多，而是「改起来费劲」 先澄清一个常见的误解：复杂度 ≠ 功能多、代码量大。 一个 50 万行的系统，如果你...

AI 编程助手已经越来越常见。很多人会用 Claude Code、Cursor、Codex CLI 这类工具来读代码、改代码、解释架构、定位 bug。 但 AI 经常会遇到一个问题，尤其是项目比较大的时候：它并不是真的掌握了整个代码库的结构，而是在不断搜索文件、读取文件、猜测关系。 比如你问：这个请求最后是怎么走到数据库查询的？ 如果没有更好的索引，AI 可能会从 route 开始搜索，打开几个 controller，再继续找 service、model、query builder。过程中它会消耗很多 token 和工具调用，而且一旦漏掉某个框架约定或隐式调用，结论就可能不完整。 而 CodeGraph 要解决的，就是这个问题。它为代码库建立一个本地的代码知识图谱，让 AI 编程助手可以直接查询代码结构，而不是每次都从零开始翻文件。 CodeGraph 是什么 CodeGraph 是一个面向 AI 编程助手的本地代码智能工具。 它会扫描项目，解析代码里的函数、类、方法、组件、路由、导入关系和调用关系，并把这些信息保存到本地 SQLite 数据库中。之后，AI agent 可以通...

最近在读 Superpowers 里的一个 skill：subagent-driven-development。 这个 skill 很有意思。它并不是教 agent 如何写某一种代码，而是在设计一种开发流程（开发+review）：当我们已经有一个实现计划，并且计划里的任务相对独立时，主 agent 不再亲自完成所有工作，而是把每个任务派发给新的 subAgent，再通过两阶段 review 来控制质量。 它的核心思想可以用一句话概括： 每个任务派一个新的 subAgent + 两阶段审查 = 可控、高质量、低上下文污染的开发流程。 也就是说，它真正关注的不是「让更多 agent 干活」，而是「如何让多个 agent 在明确边界内协作」。 一、 它解决的不是编码问题，而是协作控制问题 在 SKILL.md 里，开头就定义了这个 skill 的执行方式： 123Execute plan by dispatching fresh subagent per task,with two-stage review after each:spec compliance review fi...