企业官网建设流程全解析

1. 这不是“更聪明的自动补全”，而是一场开发范式的底层重装

去年这时候，我还在用 Copilot 写一个 React 表单组件，敲完useEffect就弹出三行建议，心里还暗自得意：“这 AI 真懂我”。直到上个月，我让 Claude Code 在一个空 Git 仓库里从零启动一个微服务项目——它自己读了package.json模板、生成了Dockerfile、写了健康检查端点、配好了 GitHub Actions 流水线，最后还跑通了所有测试。整个过程我没写一行代码，只在关键节点点了两次“确认”。那一刻我才真正意识到：我们正在经历的，根本不是 IDE 插件的升级，而是一次开发范式的底层重装。Coding Agent 不再是你的“副驾驶”，它正试图成为整架飞机的自动驾驶系统，而你，正在从飞行员转型为机长兼航路规划师。

这个转变的核心，就藏在标题里的三个关键词里：Context Engineering（上下文工程）、Subagents（子智能体）和 Harness（约束框架）。它们不是并列的技术点，而是一个层层递进的三角关系——Context Engineering 是你给 Agent “喂什么”的问题；Subagents 是你让它“怎么分工”的问题；Harness 则是你“怎么确保它不乱来”的问题。过去一年，行业讨论的焦点，已经从“AI 能不能写代码”彻底转向了“我们如何构建一套可信赖、可预测、可审计的 AI 开发基础设施”。这背后，是成本、安全、可维护性三座大山压下来的现实倒逼。我亲眼见过一个团队，把 AI 生成的代码直接合入主干，结果因为一个没被发现的eval()调用，导致生产环境 API 密钥泄露；也见过另一个团队，靠一套自研的 Harness 框架，把 AI 生成的 CRUD 服务上线周期从两周压缩到两天，且线上故障率下降了 73%。这两极分化的结果，恰恰印证了同一个道理：决定 AI 编程成败的，从来不是模型本身有多强，而是你围绕它搭建的那套“确定性骨架”有多结实。这篇博文，就是我过去一年踩坑、复盘、重构的完整实录。它不讲大道理，不画饼，只告诉你：Context Engineering 的“杠杆”到底怎么撬、Subagents 的“分身术”何时该用、Harness 的“安全网”又该如何编织。无论你是刚接触 Agent 的前端工程师，还是正在评估技术路线的架构师，这里的内容，都是你可以明天就拿去调试、部署、落地的实战手册。

2. Context Engineering：从“塞满提示词”到“设计信息流”的范式跃迁

2.1 为什么“Rules 文件”只是起点，而非终点？

一年前，我的 Context Engineering 实践，就是在一个AGENT_RULES.md文件里堆砌各种指令：“永远先写单元测试”、“禁止使用any类型”、“React 组件必须用函数式写法”。每次启动会话，我就把这个文件拖进聊天窗口。效果？时好时坏。最经典的失败案例是：我让 Agent 重构一个遗留的 AngularJS 控制器，它确实遵守了“先写测试”的规则，但生成的测试用例全是 Jasmine 语法，而项目里用的是 Jest。它“听懂”了指令，却完全没理解上下文——那个项目的技术栈、工具链、甚至团队约定俗成的命名习惯。这让我明白，早期的 Context Engineering 本质是一种“暴力投喂”，它假设模型能像人类一样，从一堆静态文本中自动推导出隐含的约束和边界。事实证明，这是个危险的幻觉。模型没有“常识”，它只有“模式匹配”。当你的 Rules 文件里混杂着通用规范（如“代码要可读”）和特定项目细节（如“所有 API 调用必须走apiClient工厂函数”）时，模型大概率会优先匹配前者，而忽略后者。

真正的转折点，发生在我开始把 Context Engineering 当作一门“信息流设计”学科来对待之后。我不再问“我要告诉 Agent 什么”，而是问“Agent 在哪个决策节点，需要哪一类信息，以什么格式，由谁来提供？”这个问题的答案，直接催生了 Skills 和 Subagents 的成熟应用。Skills 的核心价值，不在于它是个新名词，而在于它强制你进行模块化、按需加载、接口化的设计。比如，我把“前端组件开发规范”拆成一个独立的frontend-skill文件夹，里面包含：

• README.md：一个 50 字以内的能力描述，供主 Agent 快速扫描判断是否需要加载；
• conventions.md：具体的 React/Vue 规范，但只包含与当前任务强相关的部分；
• cli-tools/：一个generate-component.sh脚本，Agent 可以直接调用，生成符合规范的组件骨架。

提示：Skills 的README.md描述必须极度精炼。我试过写“请遵循公司前端最佳实践”，结果 Agent 90% 的时间都忽略了它。改成“生成 React 函数组件，使用 TypeScript，带useEffect清理逻辑”，命中率立刻飙升到 85%。模型对动词和名词的敏感度，远高于对抽象概念的敏感度。

2.2 “上下文预算”：一场关于 Token 的精密财务核算

如果说 Skills 是设计哲学，那么“上下文预算”（Context Budget）就是它的硬性财务约束。去年初，我天真地以为 200K 的上下文窗口是取之不尽的“金矿”。直到我给一个大型 Java 项目配置了一套完整的 Skills（包括 Spring Boot、Hibernate、Kafka 集成等），再加载整个pom.xml和application.yml，Session 还没开始，Context 已经占用了 65%。结果呢？Agent 在生成代码时频繁出现“思路中断”，它明明知道要写一个 Kafka 消费者，却在@KafkaListener注解后卡住，反复输出“...”和“我需要更多信息”。这不是模型能力不足，而是它被海量的、低相关性的上下文信息淹没了。Context 不是越多越好，而是越“精准”越好。它就像一个内存池，塞满了无关的缓存数据，真正需要的指令反而找不到位置。

我后来建立了一套严格的“上下文审计”流程，每新增一个 Skill 或一份文档，都必须回答三个问题：

1. 触发条件是什么？（例如：只有当任务涉及“消息队列”或“异步处理”时，才加载 Kafka Skill）
2. 最小必要信息集是什么？（例如：Kafka Skill 不需要整个application.yml，只需要spring.kafka.bootstrap-servers和spring.kafka.consumer.group-id这两个属性）
3. 它的生命周期是多久？（例如：一个用于生成数据库迁移脚本的db-migration-skill，在脚本生成并验证通过后，应立即从当前 Session 中卸载）

这套流程让我把平均 Context 占用率从 65% 降到了 32%，而 Agent 的首次响应准确率提升了 40%。一个直观的对比是：以前我需要手动删减AGENTS.md里的内容来“瘦身”，现在我只需要在skills/目录下新建一个kafka/子目录，并确保它的README.md描述足够精准，系统就会自动完成一切。

2.3 Context Engineering 的终极目标：让 Agent “理解”你的工程文化

最深刻的领悟，来自于一次失败的“架构迁移”项目。客户想把一个运行了八年的 PHP 单体应用，迁移到 Node.js 微服务。我精心准备了所有 Skills：PHP 解析器、Node.js 最佳实践、API 网关配置模板……Agent 生成的代码在语法层面完美无瑕，但部署后，所有服务都因超时而崩溃。排查了三天，才发现问题出在 PHP 的“懒加载”文化上——旧系统里，一个数据库查询可能被延迟到视图渲染的最后一刻才执行。而 Node.js 的异步模型，要求所有依赖必须在请求入口处就明确声明和初始化。Agent 完全不懂这种“文化差异”，它只是机械地翻译了代码结构。

这件事让我彻底跳出了纯技术视角。Context Engineering 的最高形态，不是灌输知识，而是传递一种“工程文化”。我随后重构了所有 Skills，不再只写“怎么做”，而是增加了“为什么这么做”的文化注释。例如，在nodejs-microservice-skill的conventions.md里，我加了一段：

“在本组织，‘快速失败’（Fail Fast）是核心信条。这意味着：任何服务启动时，必须主动连接其所有依赖（数据库、Redis、下游 API），并在连接失败时立即退出进程，而不是静默等待或重试。这与 PHP 单体应用的‘容忍性’文化截然不同。请确保生成的healthcheck端点能真实反映所有依赖的连通性。”

这段文字本身不会被模型直接执行，但它改变了模型的“决策权重”。当 Agent 再次生成健康检查代码时，它不再只关注 HTTP 状态码，而是会主动引入redis.ping()和db.query('SELECT 1')这样的探测逻辑。Context Engineering 的杠杆，最终放大的不是代码行数，而是你团队沉淀下来的、那些无法写进文档的隐性知识。它让 AI 不再是一个外来者，而成了你工程文化的“数字学徒”。

3. Subagents：从“单线程思考”到“分布式协作”的工作流革命

3.1 Subagents 的本质：不是“多开几个窗口”，而是“创建专用大脑”

很多人第一次听说 Subagents，第一反应是“哦，就是让 AI 同时开好几个聊天窗口干活”。这是一个巨大的误解。Subagents 的核心价值，不在于“并发”，而在于“隔离”与“专业化”。想象一下，你让一个全能型律师同时处理一份并购合同、一个离婚诉讼和一份遗嘱起草。他当然可以切换，但每个任务的上下文（法律条款、当事人情绪、证据链）都会互相污染。Subagents 就是为每个任务分配一个“专用律师”，他们之间不共享记忆，只共享最终结论。

我在一个大型 Vue 3 项目中，将 Subagents 应用到了极致。主 Agent 负责整体规划和协调，而它会根据任务类型，动态派生出以下 Subagents：

• code-explorer：专门负责深度阅读和理解现有代码库。它会一次性加载所有.vue文件，分析组件依赖图、状态管理流向，并生成一份结构化的CODEBASE_MAP.md。这份地图只返回给主 Agent，绝不污染主 Session。
• test-writer：一个“无历史包袱”的纯净环境。当主 Agent 决定要为某个新功能写测试时，它会启动test-writer，并只传入CODEBASE_MAP.md和新功能的 PRD。这个 Subagent 从不看任何已有代码，只基于规范生成测试用例，从而避免了“被旧代码的坏习惯带偏”。
• security-auditor：一个拥有严格权限的 Subagent。它只被允许访问src/utils/和src/api/目录，任务是扫描所有网络请求和用户输入处理逻辑，寻找 XSS 和 CSRF 漏洞。它的输出是一份带行号的漏洞报告，主 Agent 根据报告决定是否修复。

注意：Subagents 的“专用性”必须通过严格的沙箱来保障。我曾犯过一个严重错误：让test-writerSubagent 也能访问src/下的所有源码。结果它生成的测试用例，大量模仿了旧代码中已有的、不合理的 mock 方式，导致测试覆盖率虚高，但实际防护能力为零。从此，我给每个 Subagent 都配置了独立的、最小权限的文件系统挂载点。

3.2 “Fan-out” 模式：如何让 Subagents 协同解决复杂问题？

“Fan-out”（扇出）是 Subagents 最强大的工作模式，它模拟了人类专家团队的协作方式。一个典型场景是：重构一个存在 200 多个调用点的全局函数calculatePrice()。如果让主 Agent 单独处理，它会陷入“顾此失彼”的困境：改了 A 处的调用，忘了 B 处的参数变化。而 Fan-out 模式，则是这样运作的：

1. 主 Agent 发起扇出：它首先运行一个轻量级的grep -r "calculatePrice(" src/命令，生成一份所有调用点的列表CALL_SITES.txt。
2. 并行派生 Subagents：主 Agent 读取CALL_SITES.txt，为列表中的前 10 个调用点，同时派生 10 个refactor-siteSubagents。每个 Subagent 只接收一个调用点的完整上下文（所在文件、前后几行代码、函数签名）。
3. 独立分析与提案：每个refactor-siteSubagent 独立分析：这个调用点是否需要修改？如果需要，应该传入哪些新参数？修改后的代码是什么？它只返回一个简洁的 JSON 提案：{"file": "src/components/Checkout.vue", "line": 42, "proposal": "replace with calculatePriceV2(...)"}
4. 主 Agent 汇总与仲裁：主 Agent 收集所有 10 个提案，进行冲突检测（例如，两个 Subagent 都提议修改同一行）。对于冲突，它会启动一个更高权限的refactor-arbitratorSubagent，该 Subagent 可以访问所有相关文件，进行全局一致性分析，并给出最终裁决。
5. 批量执行：主 Agent 将所有无冲突的提案，打包成一个codemod脚本，交由executorSubagent 批量执行。

这个流程，将一个原本需要数小时、极易出错的手动重构任务，压缩到了 12 分钟内完成，且零错误。关键在于，Fan-out 模式把一个“全局优化”问题，分解成了多个“局部最优”问题，而 Subagents 的隔离性，保证了局部最优不会互相干扰。这正是人类工程师在面对复杂系统时，最本能的思维方式。

3.3 Subagents 的陷阱：警惕“虚假的自主性”

Subagents 带来的最大诱惑，是让你产生一种“我已经放手让 AI 自主工作”的幻觉。我曾经在 CI/CD 流水线中，配置了一个ci-runnerSubagent，让它在每次 PR 提交后，自动运行测试、生成报告、并决定是否合并。听起来很完美，直到某天，它因为一个未被识别的、极其罕见的Promise.race()时序 bug，误判了测试失败，导致一个有严重内存泄漏的版本被自动合入主干。

这次事故让我总结出 Subagents 的三条铁律：

1. 永远不存在“完全自主”的 Subagent：每个 Subagent 都必须有一个清晰的、不可绕过的“人类确认点”。在我的ci-runner中，我后来强制加入了--dry-run模式，它只生成报告，从不自动执行合并。
2. Subagents 的“专业领域”必须有明确的边界：一个security-auditorSubagent，它的职责只能是“发现漏洞”，绝不能是“修复漏洞”。修复是主 Agent 或人类工程师的职责。混淆职责，是灾难的温床。
3. Subagents 的输出必须是“可验证”的结构化数据：拒绝任何形式的自由文本输出。refactor-siteSubagent 必须返回 JSON，security-auditor必须返回 SARIF 格式报告。只有结构化数据，才能被后续的自动化流程（如静态分析、CI 检查）所消费和验证。

4. Harness：构建 AI 开发的“确定性骨架”与信任基石

4.1 Harness 是什么？它不是“护栏”，而是“操作系统内核”

在听到“Harness”这个词时，很多人的第一反应是“一个防止 AI 乱来的护栏”。这种理解太浅薄了。Harness 的本质，是为非确定性的大模型，构建一个确定性的反馈与约束操作系统。它由三大部分组成，缺一不可：

• Feedforward Layer（前馈层）：在 Agent 开始行动之前，就为其提供确定性的工具和信息。例如，一个dependency-cruiserCLI 工具，它能实时告诉 Agent：“你正在尝试从domain层直接引用infrastructure层，这违反了分层架构规则。”
• Feedback Layer（反馈层）：在 Agent 行动之后，对其产出进行确定性的验证。例如，一个定制的archunit规则，它能精确指出：“UserService类不应该依赖DatabaseConfig类，因为DatabaseConfig属于infrastructure包。”
• Orchestration Layer（编排层）：定义 Feedforward 和 Feedback 如何协同工作。例如，一个规则：“如果dependency-cruiser报告了架构违规，则禁止 Agent 进入git commit步骤，必须先修复。”

我自己的 Harness 框架，就严格遵循这个三层结构。它不是一个单一的工具，而是一个由 Shell 脚本、Python 工具和 YAML 配置组成的有机体。当我让 Agent 创建一个新的微服务时，Harness 会自动：

1. 前馈：调用service-template-generator，生成一个包含正确包结构、Dockerfile、Makefile的骨架；
2. 执行：Agent 在这个骨架上编写业务逻辑；
3. 反馈：在git commit前，Harness 自动运行archunit、eslint、prettier和一个自定义的api-contract-validator（校验 OpenAPI spec 是否与代码一致）；
4. 编排：如果任何一项验证失败，Harness 会将错误信息（精确到文件、行号、错误类型）格式化后，作为新的 Prompt，送回给 Agent，要求它“修复src/main/java/com/example/service/UserService.java第 23 行的架构违规”。

提示：Harness 的威力，不在于它能发现多少错误，而在于它能把“模糊的、主观的”质量要求，翻译成“精确的、客观的”机器可执行指令。一个“代码要整洁”的要求，Harness 会将其翻译为“每个方法不超过 15 行，每个类不超过 300 行，圈复杂度小于 10”这样的具体规则。

4.2 Harness Engineering：从“手写规则”到“用 AI 构建 Harness”的范式闭环

Harness Engineering 的最大挑战，是它的建设成本。在过去，写一个archunit规则，需要你深入理解 Java 字节码和 Spring 的类加载机制，这对大多数开发者来说是难以逾越的门槛。这导致了一个悖论：我们想用 AI 来提升开发效率，却要花更多时间去构建支撑 AI 的基础设施。

这个悖论，被 Harness Engineering 的新范式打破了。Harness 本身，也可以由 AI 来构建。我的实践路径是：

1. 用自然语言描述需求：我对 Agent 说：“我需要一个规则，确保所有@RestController类的方法，其返回类型必须是ResponseEntity<T>或Mono<ResponseEntity<T>>，不能是原始类型或String。”
2. 让 Agent 生成 Harness 工具：Agent 会生成一个response-entity-checker.py脚本，它利用ast模块解析 Python 代码（或javaparser解析 Java 代码），并实现上述逻辑。
3. 人工审核与集成：我只审核这个脚本的逻辑是否正确（通常只需几分钟），然后将其放入 Harness 的feedback/目录下。
4. Harness 自动启用：下一次 Agent 生成代码时，这个新规则就会被自动纳入反馈循环。

这个闭环，让我在一周内，为一个中型项目构建了 17 个定制化的 Harness 规则，覆盖了架构、安全、可观测性等多个维度。而这些规则，如果全部手写，至少需要我两个月的时间。Harness Engineering 的终极目标，是让“构建 AI 开发环境”的成本，低于“手动编写代码”的成本。当这个目标达成时，“用 AI 写代码”就不再是炫技，而是一种必然的、经济的选择。

4.3 Harness 的终极考验：行为正确性与“黄金速度”

所有 Harness 的努力，最终都指向一个终极问题：我们能否信任 AI 生成的代码，在功能上是正确的？这是目前最大的问号。我见过太多案例：AI 生成的代码完美通过了所有静态检查和单元测试，但在生产环境中，因为一个未被覆盖的边缘条件（例如，时区夏令时切换、浮点数精度丢失），导致了严重的业务逻辑错误。

对此，我的策略是构建一个“多层防御”的 Harness：

• 第一层：结构化测试（Structural Tests）：超越传统的单元测试，测试代码的“形状”。例如，用dependency-cruiser确保模块间依赖符合预期；用openapi-diff确保 API 接口变更被显式记录。
• 第二层：契约测试（Contract Tests）：为每个微服务定义一个consumer-driven contract，Harness 会自动验证服务实现是否满足所有消费者的需求。
• 第三层：“黄金速度”（Goldilocks Speed）监控：这是我个人最看重的一层。Harness 会持续监控每个服务的 P95 响应时间、错误率、资源消耗。如果一个新版本上线后，P95 时间从 120ms 上升到 180ms，即使它 100% 通过了所有测试，Harness 也会发出警报，并阻止其进入生产环境。因为我知道，性能的缓慢退化，往往是功能逻辑缺陷的最早征兆。

这个“黄金速度”的理念，源于我自己的一个教训。一个 AI 生成的支付服务，上线后一切正常，直到一个月后，我们发现它的数据库连接池在高并发下会耗尽。原因是一个被 AI “优化”掉的日志语句，它本应记录每一次数据库连接的获取与释放，但 AI 认为“日志太冗余”，将其删除。没有日志，就没有监控，也就没有预警。Harness 的“黄金速度”监控，正是为了捕捉这种无声的、渐进式的退化。

5. 范式转移的全景图：从“人机协作”到“人机共生”的未来图景

5.1 一张表看清范式转移的四个维度

这张表不是理论推演，而是我过去一年在三个不同规模项目中，反复验证的结果。最大的感触是：当你的目标从“写代码”转向“建系统”时，你的工作重心，必须从“与模型对话”转向“与系统对话”。你不再需要记住所有模型的 token 限制和温度参数，你需要记住的是：frontend-skill的README.md描述是否足够精准？security-auditorSubagent 的权限范围是否足够窄？archunit规则是否覆盖了最新的架构决策？

5.2 “Agent Swarms”：是未来，还是一个危险的幻觉？

最近爆火的 “Agent Swarms”（智能体集群），比如 Cursor 构建浏览器、Anthropic 构建 C 编译器，让很多人热血沸腾。但作为一个每天和 AI 打交道的实践者，我的看法非常冷静：对于绝大多数企业软件开发而言，“Swarms” 不是解决方案，而是问题的放大器。Cursor 和 Anthropic 的成功，建立在两个极其特殊的前提上：1）问题高度结构化（浏览器/C 编译器有海量、公开、权威的 Specification）；2）反馈系统极度完善（有数以万计的、能自动运行的测试用例）。

而企业软件开发的现实是：需求模糊、Specification 缺失、测试覆盖率低下、技术债堆积如山。在这种环境下，盲目投入 Swarm，只会让问题雪上加霜。我做过一个实验：让 5 个 Subagents 同时为一个模糊的 PRD（“提升用户登录体验”）生成方案。结果，它们分别生成了：一个 OAuth 2.0 方案、一个 WebAuthn 方案、一个短信验证码方案、一个生物识别方案，还有一个……一个用localStorage加密存储密码的“方案”。没有统一的上下文，没有共同的约束，Swarms 只会制造更多的噪音和混乱。

更务实的路径，是“Agent Teams”（智能体团队）。它更克制，更可控。在我的项目中，“Team” 通常由 3-5 个 Subagents 组成，每个都有明确的角色（Explorer、Writer、Reviewer、Auditor），并且由一个强大的主 Agent 进行编排。它们之间的通信，不是随意的“广播”，而是通过一个结构化的、Schema 定义的team-protocol.json文件进行。这种方式，既获得了并行处理的效率，又保留了人类对整体方向的掌控力。

5.3 未来一年，我将聚焦的三个“反直觉”方向

基于这一年的血泪教训，我对未来一年的技术投入，做了三个看似“反直觉”的决策：

1. 减少对“更强模型”的追逐，增加对“更弱模型”的 Harness 投入：与其等待 GPT-5，不如把精力投入到为当前的 Claude 3.5 和 Llama 3 构建更完善的 Harness。因为一个被良好约束的“弱”模型，其产出的确定性和可预测性，远胜于一个不受约束的“强”模型。我正在将 80% 的 AI 工程资源，投入到定制化 CLI 工具和结构化测试规则的开发中。
2. 将“AI 安全素养”列为团队核心能力，而非可选技能：我要求团队每位成员，必须能读懂lethal trifecta（接触不可信内容、访问私有数据、对外通信）的原理，并能独立配置allow list。我们每周举行一次“Harness 审计会”，每个人轮流讲解自己发现的一个 Harness 漏洞或改进点。安全，不是安全部门的事，而是每个工程师的肌肉记忆。
3. 拥抱“慢下来”的节奏，重新定义“生产力”：我取消了所有关于“AI 生成代码行数”的统计。取而代之的是，我们跟踪“Harness 自动修复的 Bug 数量”和“因 Harness 预防而避免的线上事故”。我发现，当团队不再被“快”所绑架，他们反而能做出更稳健、更长远的设计。真正的生产力，不是单位时间产出的代码量，而是单位时间降低的系统熵值。这，或许就是范式转移最深刻的意义。

我个人在实际操作中的体会是，这场范式转移，本质上是一场“去中心化”的运动。它把过去集中在少数资深工程师头脑中的、隐性的、经验性的知识，通过 Context Engineering 和 Harness Engineering，转化成了显性的、可共享的、可执行的数字资产。这不仅是技术的升级，更是团队认知模式的一次集体进化。当你开始用“设计信息流”和“构建确定性骨架”的思维来工作时，你就已经站在了新范式的入口。