分治式设计驱动开发经验总结
来自 Cikaros/ddd-methodology: 基于 pi（pi.dev）与 pi-subagents 实现的方法论工具包。
核心思想：以规则和环境约束Agent进行定向开发，以保证项目结果的可预期
本次针对onlyoffice-mcp开发经验梳理完整项目开发过程：
需求采集、确认：与客户、业主等方敲定需求要点
项目背景
项目目标
核心功能
性能要求
验收标准必须量化：明确AI生成代码的合并前覆盖率基线（建议不低于80%）、缺陷密度目标、回归拦截标准，避免"加强验收"停留在态度层面而不可审计。
设计：基于需求进行功能相关设计，设计需详尽
可行性调研：选取市面上可参考的类似项目了解核心技术并为技术选型提供支撑
功能敲定、技术要点
技术探究：以onlyoffice-mcp项目为例，在此项目基础上产出以下子项目
build_tools改造项目license_tools自授权项目docbuilder-pythonwheel库编译项目docbuilder-labSDK API探究验证项目
在设计阶段同步定义运行时契约：关键路径的可观测性埋点要求应作为设计产出的一部分，而非开发后补加。
架构设计：
技术选型、基础框架和依赖版本、代码结构与开发风格
特殊要点设计：以onlyoffice-mcp项目为例，IR协议设计
人工核查、回溯设计
机器先拦：格式、静态分析、类型检查、单测执行，不进入人工视野（约20%–25%的AI代码幻觉可由自动化结构与静态分析在写码环境中检出）；
Agent互评：由独立evaluator Agent做第一轮语义审查，人类做最终裁决，而非从零逐行阅读；
人工聚焦：架构一致性、接口契约变更、上下文越界、过度工程迹象——这些是自动化工具难以判断、而Agent恰恰最容易出问题的地方；
依据：DX 2025报告显示每日AI用户的周均merge PR量高出60%而Reviewer人数基本不变；PSP研究表明每行Review时间越少，缺陷检出率越低。笼统要求"加强人工检阅"只会导致核查动作存在、核查有效性下降。
开发、单元测试、冒烟测试
测试投入需有量化锚点：测试投入ROI在实证中可达约18:1，一名专职测试人员即可消除约70%的客户端缺陷；同时警惕AI"按自己生成的分支数当分母"制造虚假100%覆盖率，覆盖率统计应以真实需求路径为基准。
调用链路确认、架构设计核对
除静态架构核对之外，同步核对运行时契约是否被满足、关键路径可观测性埋点是否到位。
集成测试：用例设计、测试
设定可度量的集成通过标准与缺陷密度目标，作为进入第三方测试的门槛。
第三方测试：仅暴露用户可见信息（隐藏项目内部信息）进行全方位覆盖性测试
开发过程中遇到的问题：
项目时间于预期间存在波动，这源自与Agent产出与项目目标、环境、规则约束的偏差
建议： 必须人工干预，建议加强人工检阅
人工检阅须分层执行（机器先拦 → Agent互评 → 人工聚焦架构与契约），避免Review带宽被AI产出速度稀释；实证显示AI编码Agent被回滚的首要原因是"非预期副作用（22.33%）和过度工程（22.13%）"，功能性不正确仅排第三（17.71%）——人工应重点拦截越界与失焦，而非逐行重读语法。
代码、文档逐渐混乱
建议： 定期进行代码、注释、文档的治理
引入"Agent债务"视角：实证显示采用Cursor的仓库静态分析警告上升30%、代码复杂度上升41%，且指标在采用后持续保持高位；返工负担更多落在资深开发者身上（核心开发者Review量+6.5%、原创代码产出-19%）。治理不应只靠"定期"，而应把可观测性、静态分析门禁前置为Agent生成代码的默认要求。
落地项目不满足生产使用标准
建议： 建议加强验收标准，高度重视软件测试带来的收益
注意AI代码"表面质量"与运行时行为之间的系统性缺口：94%的技术负责人认为AI代码在Review时质量不低于甚至高于人类代码，但78%报告上线后事故增多、74%承认至少25%的AI代码需显著返工、82%在过去半年经历过至少一次与AI代码相关的生产故障。验收标准须覆盖运行时行为，而非仅覆盖静态Review。
设计存在认知性偏差
建议： 这与开发团队的经验相关，建议加强前期的设计过程（深度调研、会议探讨等）
偏差不只源于经验不足，也源于Review信号的误导：62%承认团队"经常信任AI代码到无需逐行人工验证就直接上生产"。应建立反偏差机制——不以"看起来质量高"作为放行依据，而以"契约是否被满足、边界是否被遵守、异常路径是否被覆盖"作为判定标准。
最终结论：
AI时代下对项目管理经验、架构设计经验、产品业务场景、测试经验要求更高了，这些人员是影响Agent软件产品质量的重要因素
核心在于为AI制定规则、规范，约束Agent可观测环境，促使Agent与项目目标契合。
控制力需从"开发时"延伸至"运行时"：将可观测性作为Agent生成代码的默认要求而非事后补加——96%的技术领导者在调查中将可观测性评为与AI代码协作"非常重要"或"极其重要"的能力。分治式设计的最终落脚点，应是可复现、可审计的工程约束，而不是一份事后回顾的原则清单。