跨会话可接续。 每次打开 IDE，AI 知道上次做到哪了、为什么那样做、哪里还没做完——不需要我重新讲一遍。
AI 的行为可审计。 它改了什么、为什么改、改之前是什么样，全链路有记录。不是事后补日志，是编码时就已经嵌在基础设施里。
人不会被黑盒替代。 系统越复杂，人应该越轻松——所有决策汇聚到单一裁决点，人可以读决策表而不是追踪散落的 if。决策一旦集中，AI 就能替你判断——这是需求直驱编程的前提。
这不是空想。这个仓库是我把十几年的元哲学思考映射到编程垂直领域的工程化尝试，先解决我自己的效率问题。
它不只是一套范式理论——里面有一个真实的农业智能体，已经过了 7 轮原子事务迭代，每一轮都在集中裁决层上做决策、在审计链路上留证据。范式和方法论是从真实代码中长出来的，不是先设计好再去找场景。
如果你也觉得有用、能降低你的编程成本和心智负担，那它也许能帮到你。
本项目不是单个代码仓库，而是一套完整的三层技术体系：
┌─────────────────────────────────────────────────────┐
│ 哲学理论层（为什么） │
│ 4 篇原创研究报告，诊断 AI 时代的工程危机并定义方向 │
│ docs/哲学理论/ │
├─────────────────────────────────────────────────────┤
│ ADD 编程范式层（怎么做） │
│ 从哲学推导出的工程方法论：可审计、可接续、可自迭代 │
│ .trae/skills/ + .trae/rules/ + MCP 工具链 │
├─────────────────────────────────────────────────────┤
│ 工程实践层（验证） │
│ 用 ADD 范式构建的大田精准耕播智能决策系统，完整验证范式可行性 │
│ src/agents/ + docs/大田精准耕播智能决策系统（farm-agent）/ │
└─────────────────────────────────────────────────────┘
哲学理论发现了问题——全链路集成 AI 导致认知降维、DSL 必然要求可审计设计、系统演化需要嵌入式路径策略。 ADD 范式给出了答案——可审计驱动开发，让 AI 编程从"单次会话黑盒"变成"跨会话可接续白盒"。 农业智能体完成了验证——ADD 范式完整落地到真实产品，经过 7 轮原子事务迭代验证。
本项目立项时，实际上同时启动了两个智能体：
| 智能体 | 角色 | 关系 |
|---|---|---|
| 团队协同智能体（co-agent） | 研发工具——负责知识沉淀、任务追踪、多团队协同 | 生产者：协助研发团队产出另一个智能体 |
| 农业智能体（farm-agent / 大田精准耕播智能决策系统） | 业务产品——负责大田耕播的智能决策 | 产出物：通过团队协同智能体协助研发出来的业务系统 |
这不是"从别的项目移植过来的"——两个智能体从一开始就是一个硬币的两面：
- 用团队协同智能体（研发工具）来研发农业智能体（业务产品）
- 在研发农业智能体的过程中，验证并迭代团队协同智能体的能力
- 农业智能体跑通后，团队协同智能体的方法论的普适性也得到了验证
仓库中
.trae/plans/farm-agent-*和.trae/reviews/farm-agent-*以及.trae/specs/farm-agent-*中的文件均围绕 farm-agent 需求展开。co-agent（团队协同智能体）是生产工具，farm-agent（农业智能体 / 大田系统）是产出物。这不是两套独立的东西，而是同一个人机协作体系的生产工具与产物。
ADD 范式不是凭空设计的。以下 4 篇原创研究报告从不同维度论证了"软件工程必须可审计"这一核心结论，共同构成了 ADD 范式的理论基石：
| # | 研究报告 | 核心问题 | 对 ADD 范式的推导贡献 |
|---|---|---|---|
| 1 | MCP+Figma+DSL 前端工程体系变革 | 人工流水线 → 自动流水线的历史性跨越中，DSL 如何保证工程可控 | "工程必须可审计"是自动流水线的底层安全底座 |
| 2 | DSL 为什么要求可审计的软件系统设计 | DSL 的抽象性需要裁决层 + 能力模型兜底，否则退化为"靠人兜底的经验系统" | 提供了"裁决层集中管理 + 组件按能力消费"的工程蓝图 |
| 3 | 全链路集成 AI 扩大认知降维风险 | 不可审计的 AI 工具导致程序员从"系统构建者"退化为"流程执行者" | 证明了"不可审计 = 不可逆退化"，ADD 是唯一的对冲方案 |
| 4 | 嵌入式路径演化策略 | 不推翻系统，而是把"演化规则"嵌入现有运行路径 | 定义了 ADD 的渐进式演进策略：不强制重构，而是在系统内植入演化基因 |
这四篇文章回答了同一个问题——在 AI 深度渗透软件工程的今天，什么样的开发范式才能保证人类不失去对系统的控制权？ 答案是：必须可审计。ADD 范式是对这一答案的工程化落地。
实践.md 给出了 ADD 范式推向行业必须填补的四个缺口及对应的填补策略。
上述四篇哲学理论共同指向同一个工程结论：软件系统必须可审计。ADD 范式正是这一结论的工程化落地，让审计从"事后补日志"变成"编码时的强制性基础设施"。
ADD 不是万能范式。用错了阶段反而拖慢迭代速度。
项目周期：
┌──────────┐ ┌──────────────┐ ┌──────────────────┐
│ MVP │ → │ MVP 收尾 │ → │ 持续迭代 │
│ SOLO │ │ ADD 预埋 │ │ ADD 全流程 │
└──────────┘ └──────────────┘ └──────────────────┘
| 阶段 | 模式 | 做什么 | 为什么不早/不晚 |
|---|---|---|---|
| MVP 早期 | SOLO | 快速验证想法，一个人加一个 AI 足以跑通核心链路 | 需求还在漂移，今天写的规则明天就改——播种前先圈地 |
| MVP 收尾 | ADD 预埋 | 核心功能收敛后，做三件事：① 写架构文档 ② 收敛类型定义 ③ 定义核心接口合约 | 功能已经稳定到可以说清楚边界了。此时不预埋，持续迭代时 AI 会在散落的 if 上继续贴 if，债务不可逆 |
| 持续迭代 | ADD 全流程 | 每个需求走完整闭环：Plan → Review → Handoff → Spec → 代码+审计 → 收敛判断 | 系统复杂度超过人脑容量，没有裁决层和审计链路就是盲飞 |
一句话判断：如果你还在"这个功能到底要不要做"的阶段，用 SOLO 快跑；如果你已经到了"核心链路跑通了，接下来要稳着加功能"的阶段，ADD 预埋；如果你已经在修复"改了这里那里爆"的问题，ADD 晚了，但赶紧上还来得及止损。
ADD 不是"写代码时顺便打日志"，而是一套覆盖全开发周期的标准化流程。完整规范见 ADD 开发工作路径与文档协同规范，以下为快速概览：
| 阶段 | 目录 | 说明 |
|---|---|---|
| Step 0 — 需求对齐 | docs/*/knowledge/ |
文档先行：更新规划说明书、架构文档、规范文档 |
| 阶段一 — Plan | .trae/plans/ |
需求方案 + 任务拆分 + 轮间交接手册 |
| 阶段二 — Review | .trae/reviews/ |
方案评审：验证依赖拓扑、原子边界是否可行 |
| 阶段三 — Handoff | .trae/plans/ |
定义每轮原子事务边界、输入输出、ADD-7 审计 action |
| 阶段四 — 逐轮开发 | .trae/specs/ |
spec + tasks + checklist 三件套 → 代码+审计 → 验证合规 → ADD-7 记录 |
| 阶段五 — 收敛 | — | 全部轮次通过 → 功能收敛；存在偏差 → 标记通知开发者决策 |
文件命名规范：{需求域名}-{核心内容}-{产物类型}-v{版本号}，一个需求的所有文件共享同一前缀，ls {需求域名}-* 一次捞全。
实际案例见
.trae/plans/farm-agent-多轮对话能力专家链路优化统一状态管理-7轮原子事务交接-handoff-v1.md及.trae/reviews/下的逐轮 spec review 记录。
整套代码架构、规则逻辑均基于以下原创三层嵌套哲学设计，由底层安全底座逐层向上延伸至体系进化能力：
核心规则：证据驱动、集中裁决、全链路可审计
- 所有技术/业务决策统一收敛至独立裁决层，杜绝逻辑碎片化；
- 代码与方案生成强制依托企业知识库可信证据，限制模型随机输出；
- 全流程节点、证据链、决策记录、异常日志永久存储，完整溯源，满足企业合规要求。
核心规则：任务状态永续、断点无缝接续
- 以唯一
task_id绑定项目全量数据（代码快照、证据链、裁决记录、迭代历史）； - 任务状态与会话完全解耦，间隔任意时长、更换设备/对话均可无损接续开发；
- 支持多轮累积式递进决策，自动汇总历史修改与需求，无需重复复述上下文。
核心规则：工程产物自主反思、自检、重构、升级
- 系统主动扫描代码缺陷、架构冗余、性能隐患，依据内置规则自主优化；
- 底层工作流、裁决规则、调度逻辑可基于实战数据动态调优；
- 实现体系内生进化，区别于传统静态工具。
ADD 范式不是纸上谈兵。我们用 ADD 范式从头构建了"大田精准耕播智能决策系统"，作为范式的完整工程验证。该项目以农业精准耕播为场景，完整落地了裁决层、全链路审计追踪、跨会话接续开发和代码自迭代能力。
项目已完成 7 轮原子事务迭代验证，全流程跑通长周期开发链路，充分证明 ADD 范式的可行性与工程价值。
完整的 7 轮演进计划和逐轮 spec review 见 farm-agent 多轮对话能力专家链路优化统一状态管理 Plan。
| 轮次 | 交付内容 | 核心能力 |
|---|---|---|
| 第 1 轮 | 类型收敛（Evidence 统一 + EvidenceRef 引用句柄） | 消除重复定义，建立证据引用体系 |
| 第 2 轮 | 简化 thinkingLevel（fast / deep 两级路由） | chat 直通 response，节省延迟 |
| 第 3 轮 | ResponseStrategy 集中裁决（自声明匹配 + 修饰器管道） | 按意图动态调整回复策略 |
| 第 4 轮 | 能力模块矩阵 + 分析上下文 + 专家注册 | 用户选择分析维度，跨轮记忆累积 |
| 第 5 轮 | 语义缓存（LRU + TTL 自主适应 + Generation 淘汰） | 相同问题复用缓存，TTL 从数据中学习 |
| 第 6 轮 | 策略演化闭环（路径质量采集 → 审计数据回流 → 策略参数自主调整） | 系统从自己数据里学习，越来越不像旧的自己 |
| 第 7 轮 | 三层审计管线闭包（AuditCallback 自动审计 + 回路一闭合） | L2 运行时审计全自动，节点零改动；TTL 自主学习回路接通 |
第 8 轮预告：架构合流闭包 — Global State Model + Cognitive Event Bus + Policy Loop。这是继 ADD 范式、独立裁决层之后的第三个里程碑：不再用局部补丁式地扩张，而是用统一的状态模型和认知事件总线把所有能力串起来，让系统有"骨架"可以承载任意规模的演化。第八轮及以后我不会很快更新，涉及到行业隐私，可能要3个月以后再公开可公开部分
大多数软件系统的决策逻辑是这样散布的：
// 在组件里
v-if="status === 3 && type !== 2 && flag"
// 在 ViewModel 里
this.canEdit = data.role === 'admin' && data.status === 'active'
// 在路由守卫里
if (user.role !== 'manager' || step !== 2) return redirect('/')
// 在 API 回调里
if (response.code === 0 && data.length > 0 && !isArchived) { ... }这是典型的"条件散落"——业务规则分散在组件、ViewModel、路由、接口回调、watcher、生命周期钩子中，没有单一决策点。后果是：
- 改一条规则要搜遍全仓库，改漏了没人知道
- 出 bug 时无法复盘"这个决策是怎么得出来的"
- 两个条件在三个地方用不同方式表达，一部分已过时、一部分还在生效
- 新人接手时唯一能做的就是在散落的 if 上继续贴 if
集中裁决层要解决的，不是"把 if 换个地方写"，而是决策权的集中：
┌──────────────────┐
原始数据 │ │
API 返回 ──────→ │ 裁决层 │──→ 能力对象 ──→ UI 只消费
用户输入 │ (唯一决策点) │
传感器信号 │ │
└──────────────────┘
- 裁决层输入：原始数据——API 返回值、用户操作、传感器信号、文档检索结果
- 裁决层输出：能力对象——
{ canEdit: true, canApprove: false, ... }或MissionContext - 组件职责：只读能力对象，做纯 UI 分支（
v-if="canEdit"），不参与业务判断
| 条件散落 | 集中裁决 | |
|---|---|---|
| 决策位置 | 全仓库散布 | 单一裁决函数 |
| 改动成本 | 全局搜索 + N 处修改 + 担心遗漏 | 改一处，全链路生效 |
| 出问题时 | 无法追溯决策路径 | 裁决函数输入输出可审计、可回放 |
| 测试方式 | 测组件渲染（间接、脆弱） | 测系统事实 expect(canRunMission(...)).toBe(false) |
| 业务规则被绕过 | 容易，多入口各自判断 | 单一入口，绕不过去 |
这正好对应了 DSL 文章 中 2.5 步法的核心主张：组件只消费能力对象，不拼业务规则。这不是架构洁癖——当系统复杂到人类记不住全部条件时，如果没有一个单一切入点能回答"这个决策是怎么做出来的"，系统就已经失控了。
集中裁决带来的最大增益是：人类从"追踪散落的 if"升级为"读一张决策表"，认知负担从 O(N×M) 降为 O(1)。这也是 ADD 范式「让人类以更高抽象层直接操纵复杂系统」的工程基础。
| 能力模块 | 功能说明 | 行业差异化优势 |
|---|---|---|
| 集中裁决层 | 唯一决策点，输入原始数据 → 输出能力对象，组件只消费不判断 | 决策权集中，改一处全链路生效，从根本上杜绝规则散落 |
| 全链路审计追踪 | 节点快照、路由决策、证据链、异常日志全量记录 | 开发流程完全白盒化，适配企业合规审计 |
| 跨会话接续开发 | 任务状态持久化，脱离会话限制断点续做 | 根治传统 AI「单次会话失忆」痛点 |
| 证据驱动生成 | RAG 知识库前置约束，输出遵循企业编码规范 | 提升代码质量，规避模型无依据随机生成 |
| 多智能体协同 | 基于 LangGraph 角色化分工，拆解复杂开发任务 | 支撑中大型项目全流程交付 |
| 代码自迭代 | 自主查错、重构、版本优化与架构升级 | 具备自我进化能力，形成长期技术壁垒 |
意图识别 → 证据检索 → 推理规划 → 交互点检测 → 集中裁决 → 结果响应
- 核心枢纽：裁决层（verdict），负责全流程决策与质量校验；
- 观测体系：
ChainTracer链式追踪 + 异步非阻塞审计日志； - 存储体系：任务全局状态持久化，与会话生命周期解耦。
- Docker 或 Podman
- Node.js >= 18
.env.development文件（已配置数据库连接、LLM 密钥等）
git clone https://github.com/xiaomingming92/codein2027.git
cd codein2027
npm install
npm run dev打开 http://localhost:3000 查看应用。
跨平台支持：所有脚本自动检测操作系统（macOS / Linux / Windows）和容器运行时（Podman 优先 > Docker）。
npm run db:start # 启动 PostgreSQL + ChromaDB（自动检测 Podman/Docker）
npm run db:stop # 停止基础设施
npm run db:status # 查看运行状态
npm run db:ensure # 完整初始化：容器检查 → Prisma 生成 → 迁移 → 初始化数据npm run kb:sync # 同步知识库 (扫描 docs/*/knowledge/ → 向量化)
npm run kb:reset # 重置知识库 (清空向量库 → 重新同步)
npm run kb:logs # 查看知识库审计日志 (最近 100 行)
npm run kb:logs:clear # 清空知识库日志
npm run kb:export # 导出知识库
npm run kb:import # 导入知识库npm run agent:diagnose # 一键诊断 LLM/ChromaDB/PostgreSQL 连通性
npm run agent:logs # 查看 Agent 审计日志 (最近 100 行)
npm run agent:logs:clear # 清空 Agent 日志| # | 文档 | 说明 |
|---|---|---|
| 1 | MCP+Figma+DSL 前端工程体系变革报告 | 2018-2026 前端工程演进全景 + 2027 预测 |
| 2 | DSL 为什么要求可审计的软件系统设计 | DSL + 裁决层 + 能力模型 + 6 步法 |
| 3 | 全链路集成 AI 扩大认知降维风险 | AI 去技能化风险分析 |
| 4 | 嵌入式路径演化策略 | 不推翻系统，嵌入演化规则 |
| 5 | 实践方法论 | 四大缺口与填补策略 |
需求文档 (PRD)
- 规划说明书 — 产品定位、功能需求、用户角色、实施计划
- Agri-Brain 农情分析智能体 PRD
- Agri-Machine 执行智能体 PRD
- IoT 感知系统 PRD
- 农机智能体 PRD
架构文档
- 技术架构说明书 — 系统分层、证据链推理、LangGraph 工程化、裁决层设计、三层审计管线
- 决策管线架构说明书 — 决策管线设计、回路一（TTL 自主学习）、回路二/三（策略演化）
- [传统 Agent vs 大田系统对比](docs/大田精准耕播智能决策系统/knowledge/01-架构/《传统Agent vs 大田精准耕播智能决策系统 — 推理链路与运行时对比》.md) — 推理链路与运行时对比分析
- RAG 知识库系统技术文档 — 完整的 RAG 数据流转、分层设计、触发流程
- 聊天实例管理文档 — 多会话管理、竞态条件防护、API 接口
ADD 范式规范
- ADD 开发工作路径与文档协同规范 — ADD 范式全流程：Plan → Review → Handoff → Spec → 审计 → 收敛
- 开发操作审计存档规范 — 开发审计写入规范
- ADD 可审计开发范式案例参考 — ADD 范式起源与实施参考
farm-agent 的 7 轮原子事务迭代全程可追溯，关键文件如下：
| 类型 | 文件 | 说明 |
|---|---|---|
| 总体规划 | Plan v1 | 7 轮完整方案、架构设计、技术选型 |
| 轮间交接 | 7 轮 Handoff | 每轮原子事务边界、恢复上下文审计查询、启动模板 |
| 任务拆分 | Execution v1 | 7 轮任务依赖拓扑 |
| 方案评审 | Review 目录 | Plan review + 逐轮 spec review（共 7 份） |
| 逐轮 Spec | Spec 目录 | 每轮的 spec + tasks + checklist 三件套（共 8 组） |
| 项目规则 | Project Rules | ADD-0 |
| AI 行为定义 | Skills 目录 | session-init（会话恢复）+ add-paradigm（开发流程）SKILL |
- 全栈框架: Next.js 16 + TypeScript
- 前端: React 19 + Tailwind CSS + Radix UI
- 后端: Next.js API Routes + Prisma ORM
- 智能体编排: LangGraph / LangChain
- 向量数据库: ChromaDB (DirectChromaClient HTTP 直连)
- 关系数据库: PostgreSQL（业务数据、审计日志、任务状态）
- LLM: 阿里云百炼 (qwen-vl-plus)
- Embedding: text-embedding-v4 (阿里云百炼)
- 文档解析: mammoth (DOCX) + pdf-parse + tesseract.js (OCR)
- 容器化: Docker / Podman
感谢以下协作者对本项目的贡献和启发：
- milktea — 在 Node RuoYi 项目中首次证明了"Layer 2 运行时审计可以完全自动记录"（Express 中间件覆盖
res.json()拦截 POST/PUT/DELETE，自动写入审计日志）。这一实践直接启发了 ADD-0.3 自动审计机制的设计。
ADD (Audit-Driven Development) 审计驱动开发范式由 xiaomingming92 于 2026 年 5 月开始系统总结和实践，思想准备始于 2014 年。首次哲学理论提交（docs/哲学理论/）时间为 2026 年 1 月。
本仓库为 ADD 范式的原始实现，Git 提交记录可验证时间线：
git log --follow --format="%ai %an %s" -- "docs/哲学理论/"2026-01-09 docs: init
2026-01-09 docs: format
2026-01-12 docs: 全链路集成 AI 扩大了不可逆的认知降维风险
2026-01-12 docs: 文档编号 / update doc name
2026-02-02 feat: 嵌入式路径演化策略
2026-05-26 docs: docs体系完善
我讨厌抄袭，所以把时间线放在这里——不是炫耀，是事实。