上一篇文章把软件工程中的知识拆成了六个层次：代码、业务逻辑、架构设计、历史决策、需求、基础知识

拆完之后，一个很自然的问题就摆在了面前：六层知识浩瀚如海，但一次具体的开发任务——比如「在退款流程里加一个超 30 天拒退的校验」——只需要其中的极少一部分。剩下的全是噪音，不仅没用，还会干扰判断

怎么从知识的海洋中，捞出刚好需要的那一滴？

这就是 Context 要解决的问题。在整个 AI Native 软件工程的链路中：

1

Knowledge → Context → Decision → Specification → Execution

Context 是第二环，承接 Knowledge，支撑 Decision。但我越来越觉得，它可能是整个链路中最难的一环

不是因为其他环节简单，而是因为这一环要解决的问题，本质上没有一个完美解

上一篇文章讨论了一个观点：软件工程真正管理的对象，也许从来都不是代码，而是知识。AI 的出现没有让知识变重要——它只是让我们不得不正视这个一直存在的事实

但文章写完之后，一个更基础的问题一直在我脑子里转：

当我们说「知识」的时候，到底在指什么？

代码算知识吗？业务逻辑呢？架构设计呢？那些只存在于老员工脑子里的历史决策呢？这些看起来完全不相关的东西，为什么都叫「知识」？

这篇文章把这个问题拆开来看

最近一段时间，一个感受变得非常清晰：AI 写代码的速度，已经远超过去了

一个 CRUD 接口、一个 Controller、一个 SQL，甚至一整个功能模块，AI 都能够很快完成

但是，在真正的业务项目里，我花费时间最多的，却越来越不是写代码

而是：

• 不知道应该改哪里；
• 不知道为什么这里要这样设计；
• 不知道有没有类似实现；
• 不知道修改之后会影响哪些地方；
• 不知道这个看起来无关的模块为什么会一起坏掉。

举一个很常见的例子，一个需求只是：修改退款流程中的某一个逻辑。看起来只是改一个 Service，结果上线测试之后，却发现：

• 积分没有发放；
• 优惠券状态异常；
• 消息通知没有发送。

最后检查代码才发现：退款流程后面还有

• MQ
• Event
• 定时任务
• 另外几个系统的监听逻辑

这些依赖关系，并没有直接写在你修改的代码里

困难的地方，从来都不是：怎么写代码，而是：如何理解这个系统

最近几个月，我开始越来越多地使用 AI 参与日常开发，起初我以为变化最大的会是 Coding

但真正用了一段时间后，我发现最大的变化其实发生在研发流程——一个我们过去习以为常、现在却开始处处「别扭」的地方

一、旧流程为什么开始别扭

一个让我一直觉得别扭的问题

我们团队的研发流程和大多数技术团队差不多：

1

需求评审 -> 技术方案设计 -> 技术方案评审 -> 开发 -> 测试 -> 上线

过去，这套流程跑得很顺，但在引入 AI 之后，我们很自然地开始让 AI 根据需求直接生成 Spec（实现规范）进行开发。这时不出意外的话，很快就遇到了一个尴尬的情况～

就是 AI 生成的 Spec 非常的详细，详细到了包含 DTO、数据库字段、SQL、Mapper、API、Migration、Unit Test，甚至每个字段的命名和类型

这时候，当我们拿着这份 Spec 去评审时，就会有些奇怪…，因为评审会上，大家真正关心的问题是：

• 整体业务流程是否合理？
• 服务之间如何交互？
• 数据应该归属于哪个系统？
• 为什么用 MQ 而不是 RPC？
• 为什么新增一张表，而不是修改已有表？

几乎没有人会讨论 refund_reason 字段是 VARCHAR(100) 还是 VARCHAR(255)

于是，我们可能会做一件更别扭的事：先让 AI 生成一份极详细的 Spec，再让 AI 把这份 Spec 「翻译」成传统技术方案模版的文档，以供评审

后来我意识到：问题不在于 Spec 写得不好，而在于我们还在用 AI 出现之前的研发流程，去套一个 AI 出现之后的协作方式

我们开发的每一个需求，基本 80% 的时间在搞清楚该改什么，只有 20% 在写代码。这不是能力原因，更是在于软件的复杂度

一个似曾相识的场景

比如接到需求：结算单状态机增加一个「部分退款」中间状态

在梳理了 SettlementService、SettlementController、SettlementStateMachine 后，改动范围很清楚——加一个枚举值，改三条状态流转路径。改动量很小，代码 review 也顺利通过。

结果上线第二天，告警来了：对账报表里部分退款的结算单被重复计入

问题出在一个没人知道的类——ReconciliationReportBuilder。它内部有一个 switch-case 遍历结算单状态来决定归入哪个科目，新增的枚举值走到了 default 分支，被当成「已结算」处理了

这个类的存在，在改代码的时候可能完全不知道。甚至不知道「我应该知道它的存在」

如果你在接手业务需求的时候也踩过类似的坑，这篇文章就是写给你的

AI 编程助手已经越来越常见。很多人会用 Claude Code、Cursor、Codex CLI 这类工具来读代码、改代码、解释架构、定位 bug。

但 AI 经常会遇到一个问题，尤其是项目比较大的时候：它并不是真的掌握了整个代码库的结构，而是在不断搜索文件、读取文件、猜测关系。

比如你问：这个请求最后是怎么走到数据库查询的？

如果没有更好的索引，AI 可能会从 route 开始搜索，打开几个 controller，再继续找 service、model、query builder。过程中它会消耗很多 token 和工具调用，而且一旦漏掉某个框架约定或隐式调用，结论就可能不完整。

而 CodeGraph 要解决的，就是这个问题。它为代码库建立一个本地的代码知识图谱，让 AI 编程助手可以直接查询代码结构，而不是每次都从零开始翻文件。

最近在读 Superpowers 里的一个 skill：subagent-driven-development。

这个 skill 很有意思。它并不是教 agent 如何写某一种代码，而是在设计一种开发流程（开发+review）：当我们已经有一个实现计划，并且计划里的任务相对独立时，主 agent 不再亲自完成所有工作，而是把每个任务派发给新的 subAgent，再通过两阶段 review 来控制质量。

它的核心思想可以用一句话概括：

每个任务派一个新的 subAgent + 两阶段审查 = 可控、高质量、低上下文污染的开发流程。

也就是说，它真正关注的不是「让更多 agent 干活」，而是「如何让多个 agent 在明确边界内协作」。

AI Coding 目前已经成为标配，但现实是有的团队效率提升 3 倍，有的团队却效果一般。问题不在 AI，而在使用方式。

一、为什么 AI Coding 会让代码变乱？

很多人把 AI 当成「更聪明的程序员」：帮我实现一个XX功能， 然后会得到一段「看起来没问题」的代码

但这种方式的问题在于：

• AI 不知道系统结构
• 不知道业务约束
• 不对最终正确性负责

它只是基于已有上下文，生成一个「自洽的结果」，而这个结果就是：代码能运行，但是很多功能偏离预期或者边界未处理

所以关键不在于AI 能不能写代码，而在于：你有没有能力约束 AI 写出满足需求的代码

二、AI Coding 工程模型（4C + 1V）

真正有效的 AI Coding，不是写 Prompt，而是一个工程模型：

1
2
3
4
5

Context（上下文控制）
Task（任务拆解）
Constraint（约束注入）
Checkpoint（过程控制）
Verification（结果验证）

这五个能力不是并列关系，而是一条执行链路：

1

Task → Context → Constraint → Checkpoint → Verification

本质是：把概率性的「生成问题」转化为「受控的执行过程」

当前，AI 的自动化「实现能力」正在迅速增强，代码生成、逻辑补全、测试构建，已经不再是主要瓶颈

目前真正决定效率上限的，正在变成：我们是否能够清晰地定义任务、边界和验收标准

当这些被完整定义后，AI 就可以自动完成实现、验证与修复，直至满足规格约束

这场变化不再是工具升级，而是工程能力结构的迁移。而规范驱动开发，正是这种迁移的实践形式

在工程讨论中，一旦提到「大模型应用开发」，立即就会出现一大堆的概念：LangChain / LangGraph、Agent Loop、Tool Calling、Memory 管理、Planning 策略、Orchestration 等等

但现实项目中，大量需求并没有复杂到需要构建运行时系统，很多场景只是希望可以封装一个能力、提供一个结构化的交互，同时可以被稳定复用

对于这类问题，更务实的路径是：不要从零构建 Agent，而是基于通用Agent 进行扩展 —— 通过编写Skills

本文将通过一个真实示例说明，如何仅通过定义一个 Skill，就实现一个完整可用的小型大模型应用