1，提示词工程-Prompt Engineering

提示词工程的本质很直接——"怎么说"决定了 AI "怎么做"。LLM 是接龙式生成，上下文决定输出方向。你描述得越清楚，它的结果越准确。

🎯 三段式起步

角色：你是一个专精 [领域] 的高级工程师
任务：帮我完成 [具体描述]
约束：
- 需要兼容 [具体场景]
- 不要使用 [某技术/某库]

🔢 拆分任务，别让 AI 做超纲大题

把复杂任务拆成几步：设计数据模型 → 写接口定义 → 实现业务逻辑 → 写单元测试。每一步都给它上一步的输出作为参考。

📝 Few-shot，给例子比讲规则高效

直接给输入输出示例，AI 照着格式来，比写一大段"输出格式要包含 code、msg、data 字段..."高效得多。

有了提示词工程的指导，就可以为每一个 Agent 配置一套专属的角色，来实现一些复杂的逻辑。也可以参考 Anthropic 这篇文章来自己手搓一个多智能框架。

---

2，上下文工程-Context Engineering

提示词工程解决了"怎么说"，但还有一个问题——信息太多也是一种灾难。

很多人觉得"多给 AI 信息总是好的"，于是把项目所有文档都塞进上下文。但 Anthropic 这篇文章指出了一个事实：LLM 有注意力预算限制，上下文越长，模型准确回忆信息的能力越差——这叫 Context Rot（上下文腐败）。所以上下文工程的本质不是做加法，而是做减法——找到"最小的有效token集合"，最大化期望结果的可能性。

但是到了2026 年，大清已经亡了114年了。市面上已经有非常多成熟的 AI Coding 工具——Cursor、Claude Code、开源社区的 Continue...咱们公司内部也有 CodeFlicker 和 Takumi。这些工具都非常的好用，本身已经很强大了。这里想聊的上下文工程不是让你"手搓"一个 AI Coding 工具，而是告诉你怎么更好地用好这些工具。工具有了，缺的只是你给它一份好的"项目说明书"。来看几个主流工具的上下文工程实践：

🖥️ Claude Code 的上下文工程

Claude Code 使用 CLAUDE.md 作为上下文配置文件，有几个实用的设计：

1. 分层加载：避免重复配置

Claude Code 支持三层配置，逐层覆盖：

用户级（~/.claude/CLAUDE.md）：你的个人偏好，比如"总是用 pnpm 而不是 npm"
项目级（项目根目录 CLAUDE.md）：团队共享的项目规范，比如技术栈、代码风格
本地级（.local.md）：本地特殊配置，比如本地数据库端口、开发环境的特殊路径
举个例子：用户级配置了"我用中文对话"，项目级配置了"这个项目用 Java"，本地级配置了"本地 MySQL 端口是 3307"——三层叠加，各不干扰。

2. Skills：把高频知识打包成模块

Skills 是 Claude Code 独特的机制，把高频使用的知识打包成可复用的模块：

.claude/skills/api-testing/
├── SKILL.md              # 概述：用于 REST API 的集成测试
├── REST-PATTERNS.md      # 最佳实践：认证、错误处理、分页
└── scripts/
    └── run-api-tests.sh  # 自动化脚本
当你让 Claude 写 API 测试时，它会自动激活 api-testing 这个 Skill，看到对应的规范和脚本。再比如你可以创建一个 sql-review Skill，封装团队的数据查询规范。

3. 子代理：复杂任务的解药

当任务太复杂时，上下文窗口会变得拥挤。Claude Code 支持用子代理处理子任务：

主代理负责规划和协调，给子代理分配具体任务
每个子代理在独立上下文运行，互不干扰
子代理完成后返回摘要（通常 1000-2000 token），主代理整合结果
举个例子：重构一个大模块时，可以让子代理 A 处理数据模型、子代理 B 处理业务逻辑、子代理 C 写单元测试，最后主代理汇总。

建议：第一次使用 Claude Code 时，执行 /init 命令，它会引导你创建一份基础的 CLAUDE.md，包含项目基本信息、技术栈、目录结构等。

⌨️ Cursor 的上下文工程

Cursor 已经从单文件 .cursorrules 演进到 .cursor/rules/*.mdc 多文件规则系统，更灵活、更细粒度。

1. .mdc 文件格式：规则也有元数据

每个 .mdc 文件头部有 YAML 格式的 frontmatter，控制规则的激活条件：

---
description: API 错误响应格式规范
alwaysApply: false
globs: app/api/**/*.java
---

# API 错误响应规范

所有 API 错误响应必须符合以下结构...

## 规则
- 永远不要返回原始异常堆栈给客户端
- 使用统一的 ErrorResponse 类
- HTTP 状态码按以下映射...
这里的 description 是规则说明，alwaysApply: false 表示只有被引用时才生效，globs 指定只在 app/api/**/*.java 下生效。

2. 作用域控制：不同规则管不同文件

你可以把规则拆分成多个文件，精准控制生效范围：

.cursor/rules/
├── project-context.mdc     # 始终生效（alwaysApply: true），项目概述
├── java-style.mdc          # glob: **/*.java，Java 代码规范
├── api-rules.mdc           # glob: app/api/**，API 开发规范
├── test-rules.mdc          # glob: **/test/**，测试规范
└── react-components.mdc    # glob: frontend/components/**，React 组件规范
当你编辑 app/api/UserController.java 时，Cursor 会自动加载 project-context.mdc、java-style.mdc 和 api-rules.mdc——不需要手动指定。

3. 规则 vs 文档：各司其职

Cursor 的 .mdc 是"规则"，docs/ 下的 Markdown 是"文档"，两者职责不同：

类型	放什么	怎么写
.mdc 规则	AI 必须遵守的约束	命令式："必须使用"、"禁止"
docs/ 文档	需要理解的背景	描述式："这个模块使用..."、"原因是..."
举个例子：

规则："禁止使用 SELECT *，必须明确列出字段"
文档："支付模块使用 Stripe，主要流程是：创建 PaymentIntent → 客户端确认 → 回调通知..."
4. 实践建议：从简单开始

不要一开始就写一堆规则。只有当 Cursor 反复犯同一个错误时，才添加对应规则。比如：

"Cursor 总是忘记加 `@DataSourceRouting`" → 加一条规则
"Cursor 不知道我们用 ResultView 返回" → 加一条规则
"Cursor 不了解业务背景" → 在 docs/ 下加文档，而不是规则

举个例子🌰：我的一个项目里的.md，给大家抛砖引玉一下。这些都是 AI 猜不到、但又高频需要的"高信号"信息。少而精，比多而杂有效得多。

项目定位：素材中台 + 爬山虎广告平台，两个业务系统的边界
数据流向：从素材到广告创意的完整链路图
    ▼                               ▼
yunfan_import_material      站内高热素材表
（云帆素材代理-Excel导入）    （快手站内视频高热素材）
    │                               │
    └───────────────┬───────────────┘
                    │
                    ▼
              final_pic / final_video（最终素材）
                    │
                    ▼（ffmpeg 规格加工：裁剪、拼接等）
              creative_pic / creative_video（广告创意）
                    │
                    ▼（AdPortalService 上传）
              creative_mapping（映射表）──► dynamic_creative（爬山虎动态创意）
                                                    │
                                                    ▼
                                              广告投放系统
核心表关系：不是所有表，只列出关键表和关联逻辑（如 creative_mapping 决定关联哪张表）
编码规范：线程池，loading cache，大表必须用 CursorIterator等等

如果需要同时用多种开发工具，也可以维护一份 AGENTS.md，主流的工具都默认支持： Cursor、GitHub Copilot、Claude Code 等。其实就是用规则文件控制行为，Markdown 文档提供背景。不要在规则里塞大量描述性内容，也不要在文档里写命令式语句就行。核心始终是：给它一张精简的地图，它反而能走得更远。其实到这里，已经足够应付一些常规的需求了。可以开开心心 vibe coding 了。只要上下文工程做的好，即使基础模型没升级，也能让性能大幅提升：

📌 同一个模型，换个环境，十倍差距

LangChain 在 Terminal Bench 2.0 测试里，没动模型，只是优化了 Agent 的工作环境——改了文档结构、加了验证回路、接入了追踪系统。排名从第 30 跳到第 5，得分从 52.8% 到 66.5%。

安全研究员 Can Boluk 做了个更极端的实验。他只改了 Agent 编辑代码的格式，Grok Code Fast 1 的得分从 6.7% 飙到 68.3%。同一个模型，换个输出格式，十倍差距。


OpenAI 的报告更直接：7 个工程师，5 个月，交付了 100 万行生产级代码。规则是——不许写一行代码，全靠 Codex Agent。

目前的局限

在一些复杂的工程项目里，很少有从 0 到 1 的。绝大部分同学维护的是祖传代码——几十号人迭代了多年，各有各的风格和写法。一个代码库里十几个 component，真严格按照上下文工程做的话，先不说编写的成本，可能每个 component 都会有自己的 CLAUDE.md、AGENTS.md、PROJECT_CONTEXT.md...加起来可能占了 50% 的上下文。同时团队又沉淀了十几个 Skills——接口开发 Skill、SQL 规范 Skill、代码审查 Skill、测试 Skill...每个 Skill 又是几百行。加上这些 Skills，又占了剩下的 50%，然后就发现上下文满了，一行代码都写不了了。

这可怎么办？其实这就是下个话题驾驭工程-Harness Engineering 要解决的问题：如何更好地管理和使用这些 Skills 和md，而不是一味地往上下文里塞东西。

---

3，驾驭工程-Harness Engineering

说实话第一次看openai的文章标题时是懵逼的😳，Harness engineering: leveraging Codex in an agent-first world。上次看到harness这个词的时候还是在搓塞尔达，他怎么就和AI扯上关系了。

仔细读了几遍发现，其实非常好的总结了我们在实际复杂项目中一直在做的事：搭建一套让 Agent 可靠工作的基础设施。不是教它做事（Prompt），不是给它教材（Context），而是给它顺手的工具、验证回路、和可控的环境。核心理念："Humans steer. Agents execute."（人类掌舵，Agent 执行）。想了半天，感觉叫驾驭工程比较信达雅一些吧🤓。

openai的文章中有几个关键实践也和大家一起分享一下：

🔌 让 Agent 能观测和验证

OpenAI 早期进度比预期慢，不是因为 Agent 能力不足，而是环境描述不足。解决方案是让 Agent 能够观测和验证：
集成日志和监控系统，Agent 可以查日志、指标、追踪
让 Agent 能够启动和驱动应用实例，验证修复是否有效
"确保服务启动在 800ms 内完成" 成为可执行的任务
一句话：Agent 看不到的 = 不存在。给它可观测性，它才能真正验证自己的输出。

📚 知识管理：AGENTS.md 是目录，不是百科全书

OpenAI 踩过的坑：巨大的 AGENTS.md（1000 页）反而导致上下文稀缺、过度引导、快速过时。
正确的做法：
AGENTS.md：目录（Table of Contents），约 100 行，告诉你"去哪找"
docs/：系统的事实来源（System of Record），design-docs/、product-specs/、references/
机械强制：用 linter + CI 验证文档时效性，防止过时

⚙️ 架构强制：让 AI 遵守边界

OpenAI 采用了分层领域架构，强制约束：
Types → Config → Repo → Service → Runtime → UI

跨域关注点（auth、connectors、telemetry）必须通过单一接口 Providers 引入
用 linter 验证依赖方向，防止 Agent 写出违反架构的代码。一个好架构不只是给人看的，也要给 Agent 看。

我们其实也不需要真的像Openai文章里写的这样，完全再手搓一遍。开源社区有一些不错的工具值得参考，他们可以极大地提高我们驾驭复杂项目的效率。

好用的开源工具

框架	使用场景	一些特性
superpowers	需要严格工程纪律的团队	子智能体驱动开发、两阶段审查、强制 TDD、Git Worktree 隔离
oh-my-claudecode	大型项目需要角色分工	专业智能体角色、监督者协调、结构化工作流
agent-scripts	需要可复用脚本和跨仓库同步的团队	Pointer-Style AGENTS、浏览器工具、提交助手、文档列表器
agent-zero	快速启动，轻量级治理	四大规则、Memory Bank、零配置启动

体验下来感觉superpowers的设计比较符合我的个人口味，有很强的指令遵循设计，也和大家分享一下：

🦸 Superpowers：强制工作流的 Skills 框架

比如说这个工程有10多个模块，是一个迭代了多年的广告创意相关的业务，相对有点复杂：

我们让他设计一个创意审核的quota分配功能。直接跑的话会这样（移除了部分内容方便展示）：

原生claude code v2.1.81：

⏺ 这是一个需要规划的功能实现任务。让我先进入计划模式，探索代码库了解现有架构和模式。
⏺ 我已经了解了项目的整体架构和现有代码：我需要进一步了解你的具体需求： 
xxx                                                                                                                                                                    
⏺ 需求已经明确：                                                                                                                                                                                     
  - 租户维度: 按业务类型划分                                                                                                                                                                         
  - 配额限制: 日级送审数量                                                                                                                                                                           
  - 超限处理: 直接拒绝                                                                                                                                                                                                                                                                                                                                                         
  让我启动一个Plan agent来设计实现方案。                                                                                                                                                             
⏺ 计划已完成。
 创意审核Quota分配功能实现计划                                                                                                                                                                       
 实现方案
 1. 数据库表设计
xxx
 2. 配置存储 (Kconf)
xxx
 3. 核心类设计
 3.1 枚举类
 3.2 配额控制服务 (参考 CreateQuotaControlService)
 3.3 配置管理服务
 3.4 数据模型
 3.5 DAO层
 3.6 API Controller
 4. 审核流程集成
 修改 /component/dsp/service/impl/DspCreativeAuditServiceImpl.java:
 1. 在 sendAuditByBizType 方法开头添加配额检查
 2. 送审成功后调用 increaseQuota 增加使用量
 5. 需要修改的现有文件
 6. 实现步骤
 │ 1    │ 创建数据模型类     
 │ 2    │ 创建枚举类        
 │ 3    │ 创建DAO            
 │ 4    │ 创建核心配额服务    
 │ 5    │ 添加Kconf配置      
 │ 6    │ 创建配置管理服务   
 │ 7    │ 创建API Controller 
 │ 8    │ 集成到审核流程     
 │ 9    │ 创建数据库表       
 7. 验证方案
 xxx

其实猛地一看还挺像那么回事，借鉴了现有的代码逻辑，公司内部的kconf之类的中间件也能很好利用。并且claude code自带的plan mode也很好的和你互动明确需求，最后完成了整体的设计以及测试方案。

但是，真这么简单就不叫祖传代码了😈。审核链路根本不走他说的DspCreativeAuditService 这个流程，这是一个早就废弃的链路，大概率他用这里做入口是因为这个服务叫创意审核服务。而实际审核的流转是完全依赖一个binlog resolver监听material_info表的几个字段流转完成的，而这个表看起来和创意审核毫不相关。

安装superpowers：

插件安装之后，会发现claude code里多了一堆skills，已经自动配置好开箱即用。

这是和他交互的过程：

⏺ 我来使用brainstorming skill帮你梳理这个创意审核quota分配功能的需求。    
⏺ Skill(superpowers:brainstorming)   
⏺ 我来帮你设计这个创意审核的quota分配功能。首先让我探索一下项目上下文，了解现有的审核流程。  
⏺ 我已经理解审核流程链路。这是一个复杂的审核系统，包含：   
  - 初审 → 复审 → 质量审 → 业务审 的多阶段流程   
  - 支持免审、人审、机审、AI审等多种审核类型  
  - 通过binlog监听触发审核流程   
  在进一步探索之前，我需要先理解你说的 "创意审核的quota分配功能" 具体是什么意思。 
⏺ 好的，现在我理解了：   
  - 配额维度：按二级策略池   
  - 周期：每天固定配额   
  - 超限处理：直接拒绝   
⏺ 这个 CreativeStrategy 看起来是一个关联创意和策略的表。让我搜索一下"二级策略池"相关的字段或概念。   
⏺ 我看到 DynamicCreative 模型中没有直接包含 subStrategyId。让我看看 MaterialInfo 模型，因为审核是基于素材的。
⏺ 我在 MaterialInfo 和 DynamicCreative 模型中没有找到"二级策略池"相关的字段。让我直接问您。  
⏺ User answered Claude's questions:  
  ⎿  · 二级策略池ID具体存在哪个字段？或者叫什么名字？ → CreativeStrategy表关联   
⏺ 明白了，二级策略池ID是通过 CreativeStrategy 表的 strategyId 字段关联查询得到的。关系链是： 
  MaterialInfo → creativeId → DynamicCreative → CreativeStrategy → strategyId
  让我继续了解配额的存储和配置方式。 
⏺ 很好，现在我对需求有了清晰的了解： 
  xxx
⏺ 让我现在提出设计方案。基于现有模式，我有几种实现方式。 
 xxx
⏺ User answered Claude's questions:  
 xxx
⏺ 现在我已经收集了足够的信息，让我提出设计方案。 
xxx
⏺ User answered Claude's questions:                                                                                                                                                                  
  ⎿  · 以上设计方案是否符合你的预期？ → 确认，继续  
⏺ 好的，让我更新任务状态并开始写设计文档。然后调用 writing计划技能。。                                                                                                                                                                                                                                                                                                                                
⏺ Write(docs/superpowers/specs/2026-03-24-audit-quota-allocation-design.md)    
⏺ Skill(superpowers:writing-plans)                  
  ⎿  Successfully loaded skill                                                                                                                                                      
⏺ 我正在使用 writing-plans skill 创建实现计划。   
 Skill(superpowers:writing-plans)                  
  ⎿  Successfully loaded skill                                                                                                                                                            
⏺ 我正在使用 writing-plans skill 创建实现计划。                                                                                                                                                                                                                                                                                                                            
  首先让我确认设计文档的位置并创建实现计划。                                                                                                                                                              
⏺ Write(docs/superpowers/plans/2026-03-24-audit-quota-allocation.md)
xxxx
Ready to execute? 

在我完全没有提示的前提下，他自己头脑风暴理解了项目的内容，准确找到了”通过binlog监听触发审核流程“。更神奇的是他竟然能问出来：我在 MaterialInfo 和 DynamicCreative 模型中没有找到"二级策略池"相关的字段。让我直接问您。他真的能问出来业务实际使用的问题！！！并且在对话的过程中他其实也在执行子任务做规划，非常神奇。最后也会逐步和你沟通确认，生成技术设计文档和实现计划文档，简直是喂饭喂到嘴里。

仔细观察就会发现，他最后写完文档会释放掉一些上下文的空间。然后阅读他刚写的这两个文档，最后生成完整的子任务列表清单再一个一个实现，过程中对上下文长度的把控非常好，一直维持在40%-60%之间：

结合上面的例子，我们其实不难发现，superpowers的这种工作方式非常契合Harness Engineering的思想，在他的加持下，我们可以真的用AI实现一些现实中复杂的业务需求：

他是强制工作流，而不是建议工作流。Agent 不会一上来就写代码，而是按这个流程来：

• 1️⃣ brainstorming：写代码前先讨论设计，AI 会展示方案给你确认，你点头才开始

• 2️⃣ writing-plans：把任务拆成 2-5 分钟的小任务，每个有精确的文件路径和验证步骤

• 3️⃣ test-driven-development：强制 RED-GREEN-REFACTOR 循环——先写测试让它失败，再写最小代码让它通过

• 4️⃣ subagent-driven-development：子代理驱动开发，两阶段审查（规范合规性 → 代码质量）

• 5️⃣ requesting-code-review：完成后提交代码审查，按严重程度报告问题

整个流程就像是给 Agent 装了一个"强制引导程序"——它不能跳过设计讨论，不能跳过计划制定，必须按流程走。 不过这种方式也有两个弊端，一个是增加了交互的次数，用起来稍微有点烦, 写一个需求得先和他聊半个小时。第二个是token消耗量还是比较大的，经常把我模型打到限额了，不过这个主要是我的问题🤡。

---

AI Coding的未来？

随着大模型能力提升，这些工程还有意义吗？以后模型能处理1000w 一个亿token、注意力完全不跑偏。这时候Context Engineering、Harness Engineering 岂不是多此一举？但实践告诉我们一个反直觉的事实：模型的上下文永远不够用。不是因为模型太笨，而是因为——代码在增长、业务在复杂、团队在扩张。你塞给它的信息越多，它能精准调用的反而越少。

所以，提供必要且精确的上下文信息——不管是写 CLAUDE.md、设计 Superpowers 工作流、还是维护团队知识库——在可预见的未来，都是 AI Coding 里非常重要的一环。这让我想到一个有点焦虑的命题：以后可能只有两种程序员了——会给自己写"说明书"的，和不会的。

玩笑归玩笑，但认真想想：你上一次给项目写 README 是什么时候？会把自己踩过的坑写成文档吗？怎么才能配置一个让 AI 高效工作的环境吗？这些能力，正在变得越来越重要。与其担心被 AI 替代，不如学会给 AI 当一个好的"导航员"。