夜雨聆风AI 抹平了不同编程语言、不同领域之间的技术鸿沟，也把开发从“只写代码”推进到了“用自然语言、Markdown、规则和工具共同编程”的新阶段。
引言与分享目标
这次分享不是介绍某一个具体的 AI 工具，也不去探讨宏观概念。我们更关心一个切实的工程问题：
研发团队如何把 AI 编程从偶尔尝鲜，变成稳定、可控、可复用的工程能力。
核心聚焦在三件事：
●理解 AI 编程从 Prompt 到 Context、Harness、Loop 的演进脉络。
●理清 AGENTS.md、Rule、Skill、Tool、MCP、Memory、Sub-Agent 这些基础设施分别解决什么问题。
●掌握一套可落地的工程协作方式：如何给上下文、如何约束 AI、如何验收结果、如何控制风险。
一个核心判断：AI 编程的门槛正在快速降低，但工程质量的门槛没有降低。
以前开发者主要管理代码、依赖、架构和测试；现在还需要管理：
●AI 能看到什么上下文。
●AI 应该遵守什么规则。
●AI 可以调用哪些工具。
●AI 的执行过程是否可追溯。
●AI 生成的结果是否符合业务和工程约束。
AI 编程不是“把需求扔给模型然后等结果”，而是一个全新的人机工程协作系统。
一、AI 编程的四个演进阶段
AI 编程的发展可以粗略划分为四个阶段：
01Prompt Engineering：会问 AI。
02Context Engineering：让 AI 看见正确的上下文。
03Harness Engineering：给 AI 配上工具、规则、权限和反馈机制。
04Loop Engineering：设计可持续运行的人机协作循环。
这四个阶段不是非此即彼的替代关系，而是层层叠加、不断增强。
架构流程示意图
1. Prompt Engineering（提示词工程）：如何与模型对话
Prompt Engineering 是最早、也最容易上手的 AI 编程方式。
●典型形态：网页或 App 里的对话框，一问一答，复制粘贴代码，让 AI 解释或修改局部片段。
●开发者角色：提问者、判断者、代码搬运工。
●核心价值：验证了大模型具备代码生成、逻辑解释与方案构思的能力；降低了语言和框架的学习门槛。
●典型问题：
○工程割裂：生成的代码游离于真实工程之外，需在网页和 IDE 之间反复搬运。
○上下文缺失：模型不清楚项目目录结构、历史规范与业务边界，易给出“逻辑上通顺但放进项目就报错”的代码。
○短期记忆：多轮对话后容易丢失前序约束，长任务难以推进。
○验收成本高：零散的代码片段仍需人工手动接入、跑测与调试。
●适用场景：学习新概念、解释单段代码、生成 SQL/正则/脚本、快速原型验证。
Prompt Engineering 的本质：让 AI 帮我们想和写，但它尚未真正进入工程现场。
2. Context Engineering（上下文工程）：如何让模型理解项目
Context Engineering 关注的核心是：如何把正确、充足且不过量的上下文精准提供给模型。
当 AI 具备直接读取项目文件、调用搜索、分析依赖与理解目录结构的能力时，它就从聊天助手跃迁为了开发副驾驶。
●典型形态：IDE 内嵌 Chat、Tab 行内补全、选中代码局部重构、基于工作区的全局问答。
●开发者角色：结对编程者、上下文提供者、方案审查者。
●核心价值：
○AI 正式进入 IDE，具备代码级上下文感知。
○遵循已有文件的编码风格生成实现。
○跨文件理解局部调用链路，人机协作效率大幅提高。
●典型问题：
○上下文过载与噪音：输入的内容越多，模型的注意力分布越不稳定，容易抓错重点。
○幻觉与过度重构：面对复杂项目易出现幻觉、误改非目标文件或过度抽象。
○缺乏全局架构感知：AI 倾向于仅解决眼前单个文件的问题，缺少全局边界判断。
●适用场景：中小规模功能开发、局部重构、单元测试补齐、阅读陌生模块。
Context Engineering 的核心原则：给 AI 恰好够用、足够准确、能有效约束行为的上下文。
3. Harness Engineering（驾驭工程）：如何构建受控系统
Harness Engineering 可以理解为 AI 工程化的控制系统。
它不仅向 AI 提供上下文，更通过工作环境、外部工具、操作规则、权限边界、沙箱隔离以及自动测试反馈，让 AI 能够稳定、规范、可度量地完成复杂工程任务。
●典型形态：Agent IDE（如 Codex、Cursor）、Agent CLI（如 Claude Code、Gemini CLI），具备自主读写文件、运行命令、执行测试、Git 提交、多 Agent 协作及长任务规划与阶段验收能力。
●开发者角色：系统架构师、产品负责人（PM）、规范制定者、最终验收人。
●核心价值：
○AI 可独立推进跨多文件的完整任务。
○形成 先规划（Plan）、后执行（Execute）、再验证（Verify） 的闭环能力。
○调用真实工具与编译器获取客观反馈，而非依赖模型自发猜测。
○在权限沙箱与项目规范约束下运作，降低破坏性操作风险。
●工程目标：
○可靠性：支持自主试错与修复，但执行边界始终受控。
○效率：降低 Token 浪费，支持并行子任务，减少人工机械干预。
○安全性：通过细粒度权限、沙箱以及敏感信息过滤兜底。
○可观测性：调用链与变更记录全程可回溯。
●典型风险：
○代码黑盒化：开发者未能逐行审阅 AI 生成的大规模代码。
○代码量膨胀：AI 倾向于堆砌冗余代码来修补问题，导致维护成本上升。
○权限越界：若赋予过大的系统命令与网络权限，可能导致误删或生产事故。
Harness Engineering 的本质：不再只钻研提示词，而是构建一套完备、可控的 Agent 工程运行系统。
4. Loop Engineering（循环工程）：如何设计可持续运转的自治循环
Loop Engineering 是更高维度的工程思路：不再依赖人类逐条输入指令驱动 AI，而是设计一套可持续运转的人机协同闭环。
2026 年中，Google 云架构团队提出 Loop Engineering 概念，强调人从“操作员”向“循环系统设计者”转变。
●核心理念：人类设计循环机制（需求输入 -> 任务拆解 -> 工具执行 -> 自动验证 -> 异常纠偏 -> 知识沉淀）。
●解决的问题：
○Agent 在长周期任务中如何避免方向漂移。
○每一轮生成的代码如何通过持续编译与自动化测试进行即时验证。
○任务执行中踩过的坑与确认的约定如何自动反哺沉淀为文档、Rule 与长期记忆。
●适用场景：大型模块重构、持续缺陷修复、自动化日常维护、多 Agent 协同流水线。
Loop Engineering 的核心：把 AI 的每次行动置于可验证、可纠偏、可沉淀的持续闭环中。
架构流程示意图
二、两种开发方式：Vibe Coding 与 Spec Coding
在日常实践中，AI 辅助开发通常呈现出两种不同风格的范式：
架构流程示意图
1. Vibe Coding（氛围编程）
Vibe Coding 的核心是让 AI 充分自由发挥。开发者提供一个大概的想法，AI 快速给出整体实现。
●工作流：提需求 -> 运行体验 -> 反馈问题 -> 让 AI 继续修补。
●优点：启动极快、反馈即时，非常适合从 0 到 1 搭建 Demo、前端原型或一次性自动化小脚本。
●痛点：
○代码极易 黑盒化，开发者难以掌控底层实现细节。
○前期写得快，后期排查偶发 Bug 和重构时成本极高。
○缺乏明确规范时，AI 容易陷入“打补丁式修代码”，越改越乱。
2. Spec Coding（规格驱动开发）
Spec Coding 的核心是：先由开发者与 AI 共同把功能规格（Spec）定义清楚，再由 AI 按规格严格执行与验证。
在写代码之前，必须显式定义：
●核心目标与技术边界（要做什么、明确不做什么）。
●输入输出格式与接口定义。
●依赖约束、性能指标与异常处理要求。
●自动化验收测试标准。
架构流程示意图
●优点：
○极大降低人机理解偏差。
○天然适配多文件重构与多 Agent 协作。
○变更记录清晰，便于回溯决策与团队维护。
●落地建议：
○需求探索期可用 Vibe Coding 快速碰撞思路。
○方案定型后切换至 Spec Coding，用清晰的 Markdown 规格文件约束实现。
○每一个阶段都配置独立验证，将定稿结论固化到 docs/ 或 AGENTS.md 中。
三、AI 编程的基础设施全景
下述概念看似繁多，但本质都可以归结为一句话：
它们的存在，都是为了把无状态的“模型能力”转化为可控、确定性的“工程能力”。
1. Prompt：任务指令与即时上下文
Prompt 是用户或系统输入给模型的完整文本，承载角色设定、当前任务与即时要求。
●作用域：单次请求 / 单个 Agent 会话。
●解决的问题：明确当前这一轮具体要做什么、怎么做、返回什么格式。
2. Rule：通用行为准则
Rule 是项目或全局层面的通用约束规则，用来显式定义 AI 应当遵守的工程红线。
●作用域：全局配置 / 项目根目录 / 子目录。
●常见内容：代码规范、技术栈选型、错误处理风格、禁用依赖库、测试要求。
●价值：避免在每次提问时重复交代基础规范。
3. AGENTS.md：项目级操作手册与长期约定
AGENTS.md 是一种开放规范，可以理解为 专门写给 AI 读的 README 与操作手册。它提交在 Git 仓库中，让不同开发者与各类 Agent 共享同一套项目背景。
●常见内容：项目架构概述、目录结构、编译运行与测试命令、开发约定、明确禁止事项。
●撰写原则：
○保持精炼高内聚：避免把几万字的业务细节和全量 API 堆在根目录 AGENTS.md 中，以免导致模型注意力涣散。
○层级就近生效：支持在子模块目录中放置针对性规则，距离目标文件越近优先级越高。
4. Instruction / Command：可按需调用的任务模板
Command（或 Instruction）是预设的标准化任务模板，通常支持通过斜杠 / 快速调用。
●价值：将高频重复的工作流程（如 /review、/generate-api、/run-test、/git-commit）固化为标准脚本，降低提示词编写成本。
5. Skill：可复用的标准化工作流 SOP
Skill 是轻量、开放、可移植的 Agent 领域能力封装。一个标准的 Skill 是包含 SKILL.md 及配套脚本、模板与参考资料的独立文件夹。
●三要素：
○name：唯一标识。
○description：触发条件（告知 Agent 何时应当按需加载该 Skill）。
○body：具体的执行步骤、约束与 SOP 指令。
●核心优势：渐进式按需加载。只有触发时才将完整指令载入上下文，避免无意义的 Token 常驻消耗。
6. Tool：赋予模型真实的工程行动力
没有工具时，模型只能返回纯文本；接入 Tool 后，Agent 才能真正进入工程现场。
●常见能力：读写文件、代码全局检索、执行 Shell 命令、调用编译器/测试套件、操作浏览器、调用 Git。
●工程要求：必须配套细粒度权限控制与审批机制，防止越权执行高危操作。
7. MCP：外部能力标准接入协议
MCP（Model Context Protocol）是由 Anthropic 主导并广泛普及的开放标准，用于将外部系统、数据源和工具标准化接入到 Agent 中。
●价值：避免每个平台重复造轮子。一套 MCP 服务的定义，可同时无缝接入 Claude Code、Codex、Cursor 等各类 AgentHost。
8. Plugin：一站式能力与配置安装包
Plugin 是对 Skill、Tool、MCP 接入、Hook、Command 以及环境配置的一站式打包与分发机制，便于团队跨项目快速同步标准化能力。
9. Agent：具备目标规划与自愈能力的执行主体
Agent 是运行在宿主环境（AgentHost）中，能够理解高级目标、自主拆解步骤、调用工具、观察执行结果并基于反馈自我纠偏的智能实体。
架构流程示意图
10. Sub-Agent：专职分工与上下文隔离
Sub-Agent 是由主 Agent 孵化并管理的专职子智能体，具备独立的上下文视窗与工具权限。
●解决的核心问题：
○上下文降噪：将繁重的大规模代码检索、日志分析剥离到子 Agent 中，保持主线程上下文的清晰干净。
○任务并行：支持多个互不依赖的模块并行修改与验证。
11. AgentHost：Agent 运行环境与生命周期调度
AgentHost 是 Agent 运行的底层系统（如 Codex、Claude Code、VSCode 插件系统等），承担生命周期管理、会话调度、权限网关、沙箱隔离以及 Tool/MCP 的统一分发。
12. Sandbox：权限隔离与安全试错环境
Sandbox 限制 Agent 进程的文件系统访问范围、网络出站以及敏感命令执行，确保 Agent 在可控的边界内充分试错，杜绝生产事故。
13. Hook：生命周期节点的自动触发机制
Hook 是在特定工程事件（如修改文件前、保存文件后、执行命令前后、提交代码前）自动触发的脚本或检查规则。
●价值：将工程约束从“指望模型自觉”转变为“系统强制拦截与校验”。
14. Worktree：多任务并行的独立代码工作区
利用 Git worktree 机制，为主任务或各个 Sub-Agent 分配独立的磁盘工作目录与分支。
●价值：多个任务并行推进时互不污染主工作区，试验性改动可安全丢弃。
15. Memory：跨会话的长期事实记忆
大模型本质是无状态的。Memory 将跨会话确认的技术选型、个人偏好、项目暗坑与关键决策持久化存储在本地文件（如 MEMORY.md），在后续会话中精准切片加载。
基础设施协同全景图
架构流程示意图
四、工程化落地经验：如何把 AI 用好
1. 上下文供给：恰好够用，拒绝泛滥
在超长上下文中，大模型的注意力分布存在天然衰减与漂移。
●推荐做法：
○明确指定目标路径：例如指明“代码位于 internal/biz 目录”。
○按需喂入相关文件：避免一股脑塞入无关依赖。
○提供结构化事实：对 Bug 给出明确的“复现步骤、期望表现、实际报错日志”。
○定期重置与整理上下文：复杂任务分步走，前一阶段定稿后及时开启新会话或重置上下文。
【任务提示词推荐结构】目标：本次修改的具体预期上下文：相关的文件路径、接口定义、报错堆栈约束：禁止改动的部分、需遵循的代码风格、禁止引入的依赖验收标准：如何验证修改成功（如执行哪条测试命令）2. 规则沉淀：把高频约束固化为 Rule 与 AGENTS.md
如果一条要求在对话中重复指正了 3 次以上，就应该立即固化到 Rule 或 AGENTS.md 中。
●适合沉淀到 Rule：语言偏好、注释规范、异常捕获方式、测试规范。
●适合沉淀到 AGENTS.md：架构说明、目录分层、常用 build/test 命令、发布检查清单。
3. Skill 沉淀：封装复杂重复工作流
针对固定步骤的工程流程（如生成标准 CRUD、编写 OpenAPI 契约、专项 Code Review、发布前安全检查），封装为轻量级 Skill。
●原则：克制安装，避免全局装入过多相互冲突的 Skill。
4. 插件与工具：克制引入，专注工程降噪
工具的价值不仅是赋能，更是工程降噪。
#### (1) 压缩工具输出：rtk
rtk：https://github.com/rtk-ai/rtk 是命令行输出压缩工具，在命令返回喂给大模型前自动过滤无意义冗余信息，大幅节省 Token 消耗。
# 原始终端输出 (50+ 行冗余字段)$ git push origin mainEnumerating objects: 15, done.Counting objects: 100% (15/15), done....To github.com:user/repo.git a1b2c3d..e4f5g6h main -> main# rtk 智能压缩后输出 (精准降噪，节省 Token)$ rtk git push✔ ok main (a1b2c3d..e4f5g6h)#### (2) 压缩模型输出：caveman
caveman：https://github.com/JuliusBrussee/caveman 约束大模型的输出风格，去除寒暄客套，用极简的技术化表达直接输出结论与代码。
【标准大模型冗长输出】当然可以！关于您提到的关于用户登录模块重构的问题，我为您编写了以下详尽的方案...（大量客套铺垫，消耗 500+ Tokens）【Caveman 极简技术输出】修改 internal/biz/user.go：增加验证码登录分支，保持原有密码认证兼容。单测覆盖率 95%。#### (3) 减少过度工程：ponytail
ponytail：https://github.com/DietrichGebert/ponytail 强调“最优秀的代码是不用写的代码”，约束 Agent 优先复用标准库与现有框架能力，遏制 AI 盲目造轮子和过度封装的倾向。
【Ponytail 核心决策顺序】1. 这个功能真的必须存在吗？非必须则不做。2. 标准库能否直接解决？能则用标准库。3. 平台原生能力能否解决？能则用平台能力。4. 项目已有依赖能否解决？能则复用已有依赖。5. 只有前面皆不可行时，才编写最小必要实现。5. 模型选择：按任务复杂度匹配模型算力
●架构设计、重构、复杂算法推导：必须使用顶级推理模型。
●日常小修小补、文档撰写、格式转换：可选用高性价比模型。
●> 好的开始远比后续反复排错修补更经济。
6. 结果验收：闭环验证，责任始终在人
AI 可以写代码，但不能替工程师承担生产责任。
●验收核心六问：
01是否完全满足需求边界？
02是否破坏了原有未改动的功能？
03是否符合项目已有代码风格？
04是否补齐了对应的单元测试与集成测试？
05是否无意间引入了非必要的第三方依赖？
06是否存在隐蔽的安全漏洞或并发风险？
五、主流工具生态与工程选型
六、AI 时代工程师的核心能力迁移
AI 的普及并未降低工程师的价值，而是促成了核心能力的重构：
架构流程示意图
01结构化思考与任务拆解：能否将含糊的业务目标转化为边界严密、步骤清晰的 Spec。
02准确描述与边界约束：用清晰的工程化语言消除二义性。
03结果验收与代码审查：具备一眼识别逻辑漏洞、并发隐患与坏味道的代码审查功底。
04工作流设计能力：掌握将 Rule、Skill、Tool、MCP 与测试闭环串联成自动化管线的架构能力。
05防御性工程意识：始终对 AI 生成的代码保持审慎，坚持自动化测试与人工 Double-Check。
七、当前 AI 的能力边界与局限
保持对当前大模型技术边界的清醒认识：
●企业内部碎片化上下文：未被整理接入工具链的口头约定、历史群聊与分散 Wiki，AI 无法凭空获知。
●业务系统的历史包袱：AI 难以理解当年妥协的历史背景与隐含的向下兼容约束。
●组织协同与权衡决策：跨部门利益协调、排期取舍与责任归属，依然必须由人来决策与推动。
●形式化正确性缺失：模型基于概率预测，无法提供绝对的数学证明，必须依靠外部测试套件兜底。
八、推荐实践清单
1. 个人实践建议
●复杂编码任务务必选用顶级模型，避免贪图轻量而耗费大量排错时间。
●保持上下文精炼，重要共识与定稿结论随时同步至本地文档。
●警惕过度安装全局 Skill，按需引入项目级配置。
●始终以自动化测试作为 AI 代码的交付门槛。
2. 团队实践建议
●在 Git 仓库根目录建立并维护 AGENTS.md。
●固化编译、测试、代码规范与 Lint 命令。
●将团队通用规范沉淀为项目内专用的 Skill 与 Command 模板。
●严格推行 Spec 驱动开发：复杂需求先对齐 Spec，再让 AI 编写实现。
●在 CI/CD 阶段设置强制质量门禁。
九、总结
AI 编程并不意味着人类从软件工程中退出，而是推动工程师走向更高维度的系统设计层级：
人负责定义目标、设计上下文、制定规则、编排工具并把控最终质量；AI 负责在受控的系统中高效执行与持续闭环。
参考资料
●工程技术：在智能体优先的世界中利用 Codex | OpenAI：https://openai.com/zh-Hans-CN/index/harness-engineering/
●Learn Harness Engineering 指南：https://walkinglabs.github.io/learn-harness-engineering/zh/
●Effective harnesses for long-running agents | Anthropic：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
●Harness design for long-running application development | Anthropic：https://www.anthropic.com/engineering/harness-design-long-running-apps
●Beyond Prompts and Context: Harness Engineering for AI Agents：https://madplay.github.io/en/post/harness-engineering
●Loop Engineering | Addy Osmani：https://addyosmani.com/blog/loop-engineering/
●Model Context Protocol 官方文档：https://modelcontextprotocol.io/docs/getting-started/intro
●Agent Skills 规范：https://agentskills.io/home
●rtk：命令行输出智能压缩：https://github.com/rtk-ai/rtk
●caveman：模型极简技术输出规范：https://github.com/JuliusBrussee/caveman
●ponytail：反过度工程 Agent 规则插件：https://github.com/DietrichGebert/ponytail
