跟着Anthropic学用Agent实现完整项目

v0_persistent

181人浏览 · 2026-07-19 19:05:32

v0_persistent · 2026-07-19 19:05:32 发布

Agent实现完整项目的整个流程

Step 1：为Agent建立规则（Rules）

举个例子

Step 2：为Agent提供项目上下文（Context）

两种情况

情况一

情况二

Step 3：与Agent进行需求对齐（Requirement Alignment）

Step 4：让Agent设计执行计划（Plan Before Code）

Step 5：让Agent自行验证（Validation）

Step 6：持续迭代（Review）

总结

很多人第一次使用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 为废弃

随后按步骤执行开发。