如何把业务需求从进入、澄清、方案、实现、CR 协同、验收、发布到结项沉淀，组织成一套能减少人工干预、能自我验收、能吸收反馈并持续成长的 Agent 研发闭环。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
本文以Android到鸿蒙的定位服务迁移为实战案例，深入剖析了AI辅助开发中通用智能与领域知识断层的根本矛盾，提出并验证了“AI + Skills”解决方案。该方案通过将API映射、枚举细节、回调差异及常见陷阱等隐性知识转化为结构化、AI可读的Skills文档，明确了AI负责通用逻辑生成、Skills提供精准领域知识的分工模型，实现了从“面向人”到“面向AI”的知识传递转变。实践表明，相比纯AI翻译的低准确率和人工查源码的低效率，AI + Skills模式不仅将单服务迁移时间缩短至30分钟且零编译错误，更在154个服务的规模化迁移中节省25小时，实现了知识的资产化、可复用与持续演进，最终展望了从静态文档向知识图谱、主动建议及组织级知识中台发展的未来路径。
适用：CodeBuddy、Cursor、Codex、Gemini CLI 等这类 AI Coding Agent。读完你会得到三样东西：一个正确的心智模型、一份今天就能做的行动清单、几套继续往下压成本的工程方法。
Superpowers 不让 AI 变聪明，而是让 AI 守纪律， 定义工程流程，强制 Claude 走"澄清→设计→规划→执行→验证"，把"写码快但漏洞百出"变成"一次做对"。
过去十几年，互联网软件的后端系统核心目标大多围绕「人类工程师友好」展开：架构要清晰，接口要稳定，日志要可查，监控要完整，发布要可控，故障要可回滚。这些原则并没有过时，但在 AI Coding、Agentic Coding、Vibe Coding 逐渐进入工程现场之后，一个新的问题出现了：如果未来大量开发、排障、重构、测试、发布工作不再完全由人类手动完成，而是由 AI Agent 7 × 24 小时持续执行，那么现有后端系统是否足够「AI Friendly」？在我看来，所谓 AI Friendly，并不是简单地「给项目加一份 README」，也不是「让代码风格更规范一点」。真正的 AI Friendly，应该是让一个 AI Agent 能够在有限上下文、有限权限、有限试错成本的前提下，正确理解系统、定位边界、拆解任务、修改代码、验证结果、评估风险、生成变更说明，并在自动化规则约束下安全地推进系统演进。
本文总结Agent Skill编写经验，将其定义为模块化领域知识资产，类似给AI的“操作手册”，适用于半自动化及专家经验导向场景。核心设计遵循三层渐进式披露架构，强调用决策树替代模糊判断、确定性操作脚本化，并建立内部自查与外部评估双重验证机制。Skill本质是以文件系统结构替代复杂运行时服务，实现零依赖部署。相比专用Agent框架，它更轻量但确定性稍弱，旨在将隐性专家经验转化为可复用、可验证的知识资产。
当 AI 输出的价值稳定超过 Token 成本之后，瓶颈从模型能力转移到了人的精力。这个认知改变了我过去半年的工作方式，这种改变的发生不是渐变式的，是某天突然看清楚了。Peter（OpenClaw作者） 一天内提交了 627 次代码——计算一下，一天有 1440 分钟，这意味着每次代码提交间隔平均不到 2.3 分钟。我看到这个数字的第一反应不是佩服，是替他感到累，这一天结束后，他还剩多少判断力？AI 在高速工作，人被绑在旁边陪跑，第二天 Token 得等他缓过来。我自己在 5 月份完成了 496 次提交，冷静下来想想，这只能说明吞吐变了，无法说明效能是否提升。提交数是过程痕迹，不是价值指标，能留下来的指标应该是：多少问题被识别，多少候选改动被挡在合入前，多少经过验证后稳妥进了主干。每一次工作方式的进化，都在回答同一件事：怎样用更少的人力在线时间，让更多的 Token 持续流动？我认为这个问题的答案不是一个更好的 IDE 插件，也不是一个更聪明的模型，是一整套云端持续进化的 Harness 基础设施。
