目录
Step 3：与Agent进行需求对齐（Requirement Alignment）
Step 4：让Agent设计执行计划（Plan Before Code）
很多人第一次使用Claude Code或任何一种Agent写一个项目或修改项目时，流程通常是：
用户：
帮我做一个城市信息网站/帮我把该项目换成企业级项目框架。
Agent：
开始规划目录...
生成代码...
安装依赖...
创建组件...
几个小时后：
- 页面能运行，但是体验很差
- 代码结构混乱
- 修改一个功能影响其他模块
- Agent不断重写之前的代码
最后发现：
Agent并不是不会写代码。
问题在于：
我们把一个复杂的软件工程问题，简单地变成了一句话Prompt。
Prompt 越短，后面踩坑的概率反而越大，因为你把原本"需求评审、技术评审"那套过滤机制跳过去了。
工程的复杂度无法通过简单的Prompt得到解决。
下面我将分享如何用好Agent实现完整项目。分享参考了Anthropic官方关于“Claude Code的最佳实践”和个人使用agent搭建项目的经验。
Agent实现完整项目的整个流程
Step 1：为Agent建立规则（Rules）
对Agent提前做好规则约束，即持久上下文信息，是提升会话效率的重点。
普通开发中，一个新成员加入项目，需要先了解：
- 项目规范
- 开发流程
- 禁止事项
否则新人直接修改代码，很容易不懂规矩，破坏已有系统。
Agent其实也是一样。
每一次新的对话，本质上都像一个新的开发者加入项目。
以Claude Code为例，CLAUDE.md是一个特殊的项目规则文件。Claude Code会自动加载其中内容，并将其作为后续开发过程中的行为约束。其中包含 Bash 命令、代码风格、工作流程规则、边界控制等。
如果使用其他Agent，也需要建立类似的“项目规则文件”，只是文件名称和加载方式可能不同。例如某些工具使用自己的rules机制，或者需要用户主动指定项目说明文件。
文件没有固定格式，但需要保持简洁。目前可参考已有的“6条规则”和“12条规则”的CLAUDE.md来写适合自己项目的规则。
举个例子
以下是github上的一个用于普遍项目构建任务的12条规则。包括规则、项目细节和核查清单。
# CLAUDE.md — 12 Rules
Drop this file in your project root. Claude Code / Codex / Cursor / Hermes all read it. Keep it short — past ~200 lines compliance drops sharply.
## Rules
1. **Think before coding.** State assumptions out loud. Surface tradeoffs. Push back when a simpler approach exists. No silent guesses.
2. **Simplicity first.** Minimum code that solves the stated problem. No speculative features. No abstractions for single-use code.
3. **Surgical changes.** Touch only what the task requires. Don't "improve" adjacent code, comments, or formatting. Match existing style.
4. **Goal-driven execution.** Define success criteria up front, then loop until verified. Prefer stating the goal over dictating steps.
5. **Don't make the model do non-language work.** Retries, routing, rate-limiting, arithmetic, time — write deterministic code, not prompts.
6. **Hard token budget.** Every loop gets a ceiling. If the same 8KB input has been re-chewed for 90 minutes, stop and step back.
7. **Surface conflicts, don't average them.** When two parts of the codebase disagree (two error patterns, two state stores), pick one visibly and explain why. Doing both doubles the bug surface.
8. **Read before you write.** Before adding code, read the nearby code. New functions that duplicate existing ones break silently through import order.
9. **Tests are gated by correctness, not "pass."** A passing test on a function returning a constant is not a passing test. Tie assertions to behavior, not shape.
10. **Long-running operations need checkpoints.** Multi-step refactors and migrations commit between steps so one bad turn doesn't require rewinding six.
11. **Convention beats novelty.** In a codebase with an established pattern, use that pattern even when yours is "better." Two patterns are always worse than either alone.
12. **Fail visibly, not silently.** A migration that "completed successfully" while skipping 14% of records on constraint violations is a bug, not a success. Surface partial failure, skipped rows, truncated output, retry exhaustion.
## Project specifics
<!--
Add repo-specific rules below. Keep it tight. Examples:
- Stack: TypeScript + Next.js 15 + Prisma + Postgres
- Test runner: `pnpm test` — uses Vitest, expects `--run` for CI
- Lint: `pnpm lint:fix` before every commit
- Never touch `migrations/` — those are managed by Prisma CLI
- Secrets live in `.env.local`, never log them
-->
## Verification checklist
Before returning a task as done:
- [ ] Did I state my assumptions explicitly?
- [ ] Did any change touch code outside the stated scope? If yes, revert or justify.
- [ ] Did any test pass without actually verifying behavior? Re-check assertions.
- [ ] Any partial failure, skipped record, truncated output? Surface it in the summary.
Step 2：为Agent提供项目上下文（Context）
在开始写代码之前，先让Agent充分理解项目，即建立项目上下文。
两种情况
情况一
从0开始的项目，你直接提出你的想法让它给出一个方案。这里提出的想法和目标的文字可以不追求什么格式，尽量说出你想要的结果是什么样的。
例如：
用户：我想做一个...（什么样的）购物的网站，请为我设计一个方案，先不写代码，与我对齐需求。
Agent就会给出类似这样的方案：
## 电商网站方案
### 1. 需求澄清
- 商品量级：初期约 500–1000 SKU
- 支付方式：微信支付、支付宝
...
### 2. 整体技术架构
- **前端**：Vue3 + Vite + Element Plus（响应式，适配手机/PC）
- **后端**：Node.js（NestJS）或 Java Spring Boot（你团队熟悉哪个选哪个）
- **数据库**：MySQL（商品、订单、用户），Redis（缓存、购物车、限流）
- **部署**：腾讯云 / 阿里云，用 Docker + Nginx，域名 + HTTPS
- **对象存储**：COS/OSS 存商品图片
### 3. 核心功能模块（MVP）
- 用户：注册登录（手机号+验证码）、收货地址管理
- 商品：分类、详情页、库存显示、图片预览
- 交易：购物车、下单、订单状态（待付款/已付款/发货/完成）、取消/退款申请
...
### 4. 非功能与安全
- 接口限流、防刷单、SQL 注入/XSS 防护
- 用户密码加密、敏感信息脱敏
...
### 5. 简要目录结构
...
情况二
在已有的项目基础上增加功能或者修改，这时需要提供关于原本项目的信息。以一个web项目为例，创建一个"PROJECT_CONTEXT.md"文件，内容有“项目介绍”、“技术栈”、“项目目录”、“系统架构”等，在agent给出方案前先阅读，让它足够了解已有的项目是什么样的。
"PROJECT_CONTEXT.md"文件例如：
# Carbon-Emission-WebGIS
# 项目介绍
本项目是一个面向城市信息的 WebGIS 平台。
目前实现：
- 用户认证功能
- 用户名密码登录（默认账号admin/123456）
- 登录状态持久化（LocalStorage存储Token）
- 路由访问控制（未登录拦截非登录页）
- 退出登录（清除Token并重定向至登录页）
- 地图可视化功能
- 天地图底图加载（路网、卫星、混合三种模式）
- 底图切换（支持切换到天地图）
- 行政区划边界叠加与显隐控制
...
# 技术栈
前端
- Vue3
- OpenLayers
- ECharts
...
# 项目目录
src/
components/
│ UI 组件，负责页面展示，不直接处理业务逻辑。
...
├── utils/
│ 通用工具函数。
# 系统架构
...
Step 3：与Agent进行需求对齐（Requirement Alignment）
调整agent给出的方案使其符合你的预期结果，即需求对齐（Requirement Alignment）。检查它给出的详细方案，补充或修改你想要的细节效果，给出完整的经过调整后让你满意的方案。
例如告诉Agent：
“我需要...，请你增加我的需求并再次生成方案”
Step 4：让Agent设计执行计划（Plan Before Code）
设计执行plan，对应的软件工程就是Sprint Planning，也是Anthropic官方强调的Small Increment。实现一个完整的项目，特别是结构复杂、逻辑严密的大型项目，让agent直接基于你的方案一次性构建也是不现实的，考虑到大模型有限的上下文、保证局部代码正常、确保执行编码方向没有偏离等，需要设计一个执行plan，
例如：
用户：给我一个该方案的实现流程和方式。先给实现计划，不写代码。
Agent就会提供一个实现阶段，例如：
## 实现阶段（推荐顺序）
Phase 1: 创建数据库建表 SQL + db.json 数据导入脚本
Phase 2: 创建 Spring Boot 项目骨架、Entity、Repository、DTO
...
Phase 7: Docker Compose 编排
Phase 8: 清理文档、标记 json-server 为废弃
随后按步骤执行开发。
Step 5：让Agent自行验证（Validation）
每完成一个任务，让Agent自行验证。在每执行完一个任务后，自行检查执行结果是否达到效果，给出验证标准（或告诉它你想要的验证标准），错误时找出根本原因。
Step 6：持续迭代（Review）
按步骤执行任务，根据验证结果调整方案，逐步完成整个项目，并通过 Git 等工具管理每个阶段的修改。
总结
Agent并不是一个输入需求、输出代码的自动化工具，而更像一个需要被管理的开发成员。
想让Agent稳定完成复杂项目，关键不是让它一次性生成更多代码，而是让它在正确的信息、规则和反馈机制下逐步完成任务。
一个可靠的Agent开发流程应该包括：
第一，建立项目规则（Rules）
通过CLAUDE.md或其他Agent支持的规则机制，明确代码规范、工作流程和修改边界，让Agent知道应该如何工作。
第二，提供或构建项目上下文（Context）
先让它分析需求、制定方案，或通过项目文档让Agent理解目标、技术栈、架构、目录结构和已有约束，减少它基于猜测进行开发。
第三，需求对齐（Requirement Alignment）
不要直接要求Agent写代码，而是先让它确认需求、调整方案。
第四，拆解任务，逐步实现（Plan Before Code）
将复杂项目拆分成多个可验证的小任务，避免一次性修改过多内容导致方向偏离。
第五，自行验证（Validation）
每完成一个阶段，都需要通过测试、Review和验收标准检查结果，让Agent根据反馈不断修正。
第六，持续迭代（Review）
最终，Agent开发的本质不是“让AI替代程序员写代码”，而是改变软件开发的协作方式：
人负责目标、判断和决策，Agent负责执行、探索和实现。
408
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
