1. 先说项目背景内部项目改造为什么偏偏要啃 AIcoding 这块硬骨头做内部项目改造这件事表面上是改代码本质上是在给一坨“能跑但没人敢动”的系统做外科手术。老项目的问题谁都清楚文档跟不上代码、模块边界模糊、一个改动牵一发动全身再加上团队里每个人的技术栈和理解程度都不一样代码评审到最后往往变成“谁嗓门大听谁的”。这种情况下引入 AIcoding很多人第一反应是“让AI帮我改代码”但真正落地后你会发现问题根本不在生成代码这一步而是你根本说不清“改什么、为什么改、怎么算改完”。我负责的就是这样一个内部系统改造项目。核心痛点是模块A里有一段历史逻辑牵扯到上游数据格式变更和下游两个调用方既要保证线上行为兼容还要顺便把长期积累的技术债清掉。需求看起来清楚但一到落地就含糊什么叫“兼容”哪些行为可以变、哪些不能变改了之后怎么证明没改坏这些问题靠口头沟通和Jira描述根本说不清。所以我尝试了一套流程在 AIcoding 的每个迭代里先写一份 intent.md把“意图”固化成文件再搭一套持续评测机制每次改动自动跑回归、跑约束检查。这套做法不是从网上抄来的是踩了几次坑之后总结出来的。这篇文章就聊聊这套流程怎么设计、怎么写 intent.md 才算合格、评测怎么做才不会自欺欺人以及我实际踩过的那些坑。如果你也在内部项目里用 AIcoding 做改造或者正准备引入类似的流程这篇应该能帮你少走不少弯路。即使你用的是别的编码助手或者纯人工改造这里面的意图拆分和评测思路同样能套用。2. 把意图说清楚intent.md 到底是个什么文件2.1 它不是一个 prompt而是“需求-约束-验收”三位一体的契约很多人第一次接触 intent.md 会误以为它是给 AI 写的一大段提示词于是写出来的东西长这样“请帮我优化模块A的逻辑保持兼容注意性能代码要清晰。”这种描述放到 AIcoding 里生成的代码大概率华丽但不可用因为 AI 不知道“兼容”的边界在哪不知道“优化”的具体指标是什么更不知道验收标准有多严格。我理解的 intent.md是给人和 AI 共同看的一份契约文件核心解决三个问题现状是什么、目标是什么、边界在哪里。它不负责指导 AI 怎么写代码那由代码仓库的具体实现去承载它只负责让 AI 和后续评审的人对“这次改造到底要做什么”达成一致。一份可以用的 intent.md通常包含这样一些字段我拿表格列出来字段作用举例meta记录任务编号、目标模块、改造类型任务ID: MOD-2048模块: order-service类型: 逻辑调整背景说清楚现状问题和改造原因上游数据源将 status 字段从 int 改为 string导致解析失败意图描述需求发生的变化指向行为而非方案解析逻辑须同时兼容 int 和 string输出统一为内部标准枚举约束列出不可触碰的红线和性能底线不得改动对外接口签名单次解析平均耗时不得超过原实现 1.2 倍禁止引入新的外部依赖验收可判定的通过条件供后续评测使用构造 10 条旧格式数据、10 条新格式数据全部解析通过且结果一致关联链接到相关代码、文档、测试用例关联模块: order-parser依赖:>