AI-native 编码范式：从知识工程到可执行软件系统

文章主旨：

AI 系统若要长期可靠地创造价值，核心不在于模型能力本身，而在于知识工程——即知识能否被有效组织、读取、验证、执行并回写，而 AI-native 软件工程则是这一逻辑在编码场景下的具体展开。

关键要点：

• 知识工程的核心是让知识进入执行闭环，解决"当前事实是什么、谁可修改、如何验证、如何更新"等问题，而非简单堆砌资料。
• 一套 AI-native 知识工程方法论需包含高层约束、知识管理、任务识别与分析、计划与执行控制、验证与反思五个协同能力块。
• 软件系统本身就是知识的可执行形态，AI coding 的关键断裂在于高层原则进不了运行时、工程知识难以转化为稳定能力、执行结果难以回流学习。
• AI coding 工作系统需要将需求任务化，并通过 story、QAS、TDD、plan、progress 等资产将角色、知识、代码、测试、评审与回写串联成完整资产生产线。
• 自动化与低人工干预的前提是稳定的单线程闭环、隔离 worktree 并行、可恢复的长时间运行，以及工具层提供的结构化输入、最小权限、副作用隔离等确定性约束。

内容结构：

1. 知识工程的核心：让知识进入执行

作者指出，多数组织并不缺资料，但资料多不等于知识工程做得好。资料回答"东西在哪里"，知识工程回答"什么是当前事实、谁可修改、何时读取、如何验证、如何更新"。人类面对混乱资料可依赖经验与默认语境，而 AI 缺乏这种语境，会在权威关系混乱时产生看似合理实则高风险的综合。因此，AI-native 知识工程的目标是让 AI 在正确阶段读取正确知识，并让执行结果重新回到知识系统，形成"筛选—能力化—执行—验证—更新"的知识生命周期。

2. 一套 AI-native 的知识工程方法论

作者认为，仅靠单次对话无法稳定承载长期原则、组织偏好与历史经验，因此方法论需区分为五大能力块并协作：
- 高层约束：定义好结果、偏好方法、边界与需停下确认的风险点，是系统长期稳定的方向来源；
- 知识管理：区分正式知识与候选材料，明确读取、过期与沉淀规则；
- 任务识别与分析：执行前先判断任务类型、复杂度、风险与知识缺口；
- 计划与执行控制：计划不是 todo list，而是包含步骤拆解、产物要求、状态记录与进入条件的执行协议；
- 验证与反思：任务结束后判断产生了哪些新知识，并更新规则、测试与失败模式。
这些能力块组合构成可长期工作的 AI 系统。作者随后介绍了其产品实践 MindFlow（GitHub 链接），该系统通过状态文件、计划与验证记录实现任务中断恢复、偏离暴露与经验沉淀。

3. 软件本身也是知识

软件工程是知识工程更典型的场景。业务判断、领域概念、架构约束与正确性标准已被分别压缩进分支逻辑、对象模型、模块边界与测试用例中。过去人充当知识与代码的转换器；AI coding 使知识直接进入执行过程，因此 AI-native 软件工程的核心不是"模型更会写代码"，而是"软件工程中的知识变得可执行、可验证、可回写"。作者同时解释了团队用 AI 后"兴奋与不安并存"的原因：模型更快，但混乱也更快——未澄清需求就已实现、未固定边界就已补默认假设、未设计测试就已宣布完成。

4. AI coding 的三个断裂

将知识工程放入软件场景，可看到三类典型断裂：
- 高层工程原则进不了运行时：团队偏好、风险边界与业务判断停留于人脑或零散文档，Agent 实际执行时只能读到局部需求；
- 工程知识难以稳定转化为能力：复盘、测试遗漏与架构约束若不能自动触发后续检查，知识就只是存档而非执行能力；
- 执行结果难以回流学习：合并代码后，新规则与失败模式未进入长期知识系统，换人或换 Agent 需重新解释。

5. AI coding 工作系统如何串起来

作者提出了资产生产线式的项目仓库结构：
- references/：输入矿石，存放聊天记录、会议纪要与临时材料，不等于稳定知识；
- knowledge/：固定知识资产，承担单一权威来源角色，存放领域规则、架构约束、QA 策略与交付经验；
- products/：围绕 MVP 或 story 形成的知识 diff，描述增量变化；
- plans/：执行控制台，包含总路径、前后端计划、接口契约、评审结论与进度；
- src/：保持代码产物纯粹，agents/ 存放编排器与角色技能。
关键设计是 QAS（测试用例与验收场景）与 story 同层出现，在开发前回答"用户要什么"与"如何证明实现"，并由此引出 TDD——测试先行定义正确性边界，约束 Agent 的自由度。需求不直接流向代码，而是先变成 story、QAS、设计、计划与状态，由 QAS 生成测试，再进入实现，最后通过验收并回写知识库。真正的完成由业务路径、测试证据、评审处理、状态更新与知识回流共同证明。

6. 自动化不是跳过流程，而是复制稳定闭环

作者强调"无人值守开发"的危险在于把自动化等同于无人管理。合理的路径是：先跑通单线程闭环（输入→任务化→澄清→设计→计划→实现→测试→验收到回写），再用 worktree 并行复制闭环到多个隔离增量，最后实现长时运行。长时间运行需依赖 feature list（防范围蔓延）、progress file、clean state、自动测试与可观测轨迹。低人工干预不等于取消治理，而是人控制目标、边界、风险与验收，系统负责增量推进，遇到高风险操作时停下请求人工确认。工具层需承担五类确定性约束：结构化输入、最小权限、副作用隔离、稳定错误协议、可审计轨迹，将不确定性关在可观察、可恢复、可验收的边界内。

7. 编码范式的变化

代码仍是关键执行表达，但 AI 将问题定义、知识组织、验收设计与工具约束等隐性工程活动放大。程序员的核心价值从"把需求翻译成代码"转向"可执行知识系统的设计者"，需定义问题、组织知识、设计流程、编写 QAS 与测试、设置工具边界并回写失败经验。AI-native coding 的成熟标志是三个硬指标：任务能否被恢复、结果能否被证明、经验能否进入下一次执行。范式变化最终体现为：模型负责推理，流程负责约束，状态负责恢复交接，测试负责定义正确性，工具负责限制副作用，回写负责形成复利；人从单点编码移动至系统设计层。

文章总结：

本文是一篇系统性阐述 AI-native 知识工程与 AI coding 实践方法的文章，逻辑层层递进，从知识工程原理到软件场景断裂，再到具体仓库结构与自动化边界，最终落脚于程序员角色向"可执行知识系统设计者"的转变；整体基调理性务实，强调用流程、状态、测试与工具约束将 AI 能力转化为可积累的工程资产。作者最后声明原创内容采用 CC BY 4.0 授权。

从0到量产：汽车IPD全流程落地实战案例（内含阶段详解）

了解更多

卷书成船

查看原文：AI-native 编码范式：从知识工程到可执行软件系统

文章来源：

卷书成船

扫码关注公众号