Claude Sonnet 4.6 编程实战：从一句需求到可测试、可回滚的完整项目

你只说了一句“帮我写一个任务管理网站”，Claude 很快返回几百行代码。

看起来效率惊人，但接下来的问题一个比一个具体：文件该放在哪里？依赖怎么安装？为什么搜索后页面没有刷新？这段代码会不会把原来的功能改坏？

问题不一定是 Claude 不会写代码，而是你还没有建立一套让 AI 稳定交付代码的流程。真正有效的 AI 编程，不是“一句话生成整个项目”，而是把需求拆解、代码生成、测试排错、代码审查和迭代交付串成一条可验证、可回滚的流水线。

本文以“带搜索、标签和本地存储的个人任务管理器”为案例，完整走一遍从需求到交付的过程。文中使用 Claude Sonnet 4.6 作为编程助手，具体模型标识、上下文长度、最大输出和价格，请以你实际使用渠道的最新页面为准。

一、先校准预期：Claude 能写代码，但不能替你负责

新手与熟练用户的区别，往往不在于会不会写提示词，而在于是否知道结果应该怎样被验收。

新手通常这样问：

帮我写一个任务管理网站，要好看、好用。

这句话没有说明技术栈、存储方式、目录结构和验收标准。模型只能自行补全空白，最终可能给出一套“看上去完整”、实际却难以接入现有环境的代码。

更稳妥的表达是：

使用 Vite、React 和 TypeScript 开发个人任务管理器。

必须支持：
1. 新增、完成和删除任务
2. 按关键词搜索
3. 使用标签筛选
4. 数据保存在 localStorage
5. 刷新页面后数据不丢失

限制：
不使用后端
不引入状态管理框架
不修改无关文件
搜索词为空时显示全部任务

验收标准：
npm install 后可以启动
搜索和标签筛选可以同时生效
localStorage 内容损坏时页面不能崩溃
核心筛选逻辑需要测试

前者是在“许愿”，后者是在“下任务单”。

Claude 更适合承担以下角色：

• 解释陌生代码和调用关系
• 把模糊需求拆成可执行任务
• 按范围修改多个相关文件
• 根据日志推测故障原因
• 生成测试、补丁和审查意见

但技术选型、权限边界、生产部署、数据库迁移以及最终验收，仍然必须由人决定。

AI 可以成为效率很高的结对程序员，但项目负责人依然是你。

同时，不要把生产数据库密码、API 密钥、用户隐私数据以及未脱敏的公司代码直接粘贴给任何模型或第三方服务。

二、选择接入方式：网页、IDE 和 API 不是一回事

模型负责理解与生成，客户端负责收集上下文、展示结果，API 服务负责把请求发送给模型。三者并不是同一个概念。

如果只是学习函数、解释报错或生成小段代码，网页对话已经够用。进入真实项目后，更适合使用能读取目录和生成 Git Diff 的 IDE 或命令行工具。

当你希望批量审查提交记录、自动分析日志，或者把 Claude 接入自己的产品时，再考虑 API。

基础环境不需要复杂：

• VS Code 或其他代码编辑器
• Git
• Node.js 或 Python
• 对应项目的测试工具
• 一个能够调用模型的客户端或 API Key

配置密钥时使用环境变量，不要写进源代码：

export ANTHROPIC_API_KEY="your_api_key"
export CLAUDE_MODEL="发布时实际可用的模型标识"

还应将真实环境文件加入 .gitignore：

.env
.env.local

对于中国用户，网络可用性、模型价格、计费单位、上下文限制和数据处理规则，可能因渠道而异。不要根据旧文章里的数字做预算，应在实际使用页面核对：

• 当前模型标识
• 最大上下文与输出限制
• 输入和输出分别如何计费
• 是否保存请求内容
• 是否支持设置费用上限

最稳妥的做法，是先用一个函数完成最小连通性测试，不要一开始就把整个代码仓库导入上下文。

三、完整实战：先做规格，再写代码

这次项目选择一个前端任务管理器，原因很简单：结果可视化、规模可控，同时包含状态管理、搜索过滤、本地存储和异常处理，足以暴露 AI 编程中的常见问题。

整个过程固定拆成 7 轮：

1. 澄清需求

2. 确认技术栈

3. 生成目录和实施计划

4. 实现任务数据结构与存储

5. 实现列表和操作功能

6. 实现搜索与标签筛选

7. 补充测试并进行 Code Review

这比“一次生成全部项目”多了几轮对话，却能显著缩小每次修改的影响范围。

第一步：强制模型先提问

你是一名资深全栈工程师。请先不要写代码，而是分析下面的需求。

项目目标：
开发一个带搜索、标签和本地存储功能的个人任务管理器。

目标用户：
需要在浏览器中记录个人事项的普通用户。

必须实现：
1. 新增、完成和删除任务
2. 按标题搜索任务
3. 按标签筛选任务
4. 使用 localStorage 保存数据

技术限制：
前端：React、TypeScript
后端：无
数据存储：localStorage
运行环境：现代桌面浏览器

请先输出：
1. 你对需求的理解
2. 仍需我确认的问题
3. 功能拆分与优先级
4. 验收标准
5. 建议的项目目录

在我确认之前，不要开始生成代码。

这一步的价值不是让 Claude 表现得更“聪明”，而是提前暴露分歧。例如：标签是否允许多选？搜索是否区分大小写？删除操作是否需要确认？

这些问题如果不在写代码前确定，就会变成后面的返工。

第二步：每轮只交付一个任务

项目目录可以控制在以下范围：

src/
├── components/
│   ├── TaskForm.tsx
│   ├── TaskList.tsx
│   └── TaskFilters.tsx
├── hooks/
│   └── useTasks.ts
├── utils/
│   ├── storage.ts
│   └── filterTasks.ts
├── types/
│   └── task.ts
├── App.tsx
└── main.tsx

然后使用分阶段实现模板：

根据已经确认的规格，现在只完成第 1 个任务：任务数据结构与本地存储。

当前项目目录：
[粘贴目录结构]

相关文件：
[提供本轮相关文件]

要求：
不修改与本任务无关的文件
不引入未经说明的新依赖
保持现有接口兼容
为新增逻辑补充测试
输出完整修改说明和验证命令

请先简述实施方案，再给出最小必要修改。

每轮完成后，至少执行一次本地验证，并保存可回滚节点：

npm run test
npm run build
git add .
git commit -m "feat: add local task storage"

不要接受“理论上可以运行”。AI 说测试能通过，与测试命令真的通过，是两回事。

四、第一次运行不是终点：保留一个真实故障入口

任务管理器最常见的问题之一，是新增任务后列表更新了，但搜索结果没有同步刷新。

此时不要只发一句“代码报错了”，更不要让 Claude 重写整个项目。你需要提供完整的故障上下文：

请帮助定位以下问题，不要直接重写整个项目。

预期行为：
输入搜索词后，新增一个标题匹配的任务，该任务应立即出现在搜索结果中。

实际行为：
任务已经写入 localStorage，但搜索结果没有更新；清空搜索词后可以看到新任务。

复现步骤：
1. 输入搜索词“报告”
2. 新增任务“完成周报报告”
3. 观察当前列表

错误日志：
控制台没有异常。

最近的代码改动：
新增了 filterTasks，并使用 useMemo 缓存搜索结果。

请按以下顺序回答：
1. 最可能的 3 个原因
2. 如何逐项验证
3. 最小修复方案
4. 修复可能带来的副作用
5. 需要补充的回归测试

在这个场景中，应重点检查 useMemo 的依赖项是否遗漏了任务列表。正确的流程是：

1. 稳定复现问题

2. 缩小到筛选逻辑或缓存依赖

3. 查看相关文件和最近的 Diff

4. 生成最小补丁

5. 执行回归测试

6. 确认没有破坏标签筛选

需要特别说明：本文不虚构“耗时几分钟、成本几元”之类的测试数字。实际调用成本受模型、渠道、上下文、缓存策略和输出长度影响。发布实测记录时，应明确测试日期、调用轮次、输入输出统计口径，并附带后台费用截图；没有可核验记录，就不要写伪精确数字。

五、从“能运行”推进到“可信赖”

修复完成后，把 Git Diff 交给 Claude，而不是再次发送整个项目：

请审查下面的 Git Diff，重点检查：

1. 功能逻辑错误
2. 空值、异常和边界条件
3. 安全与隐私风险
4. 性能问题
5. 是否破坏现有接口
6. 测试覆盖是否充分

请按“严重 / 中等 / 建议”分级，只指出有明确依据的问题。
对于每个问题，说明文件位置、触发条件和最小修复建议。

还可以分三轮审查：

• 逻辑审查：搜索、标签和完成状态组合时是否正确
• 安全审查：是否把用户输入直接注入 HTML，是否泄露密钥
• 性能审查：是否存在无意义重复计算和重复渲染

模型给出的审查意见仍然只是候选结论。进入主分支之前，请完成人工验收：

• [ ] 代码能够在全新环境安装并启动
• [ ] 所有依赖和 API 都真实存在
• [ ] 核心功能有明确验收步骤
• [ ] 自动化测试已经执行，而非仅由 AI 声称“可以通过”
• [ ] Git Diff 中没有无关的大范围改动
• [ ] 没有把密钥、用户数据和公司代码写入提示词
• [ ] 失败后能够回滚到上一个可运行版本
• [ ] 部署、权限和数据库操作经过人工确认

六、进阶工作流：让 Claude 每次都遵守同一套规则

当项目变大，只靠聊天历史很容易失控。更稳妥的方法，是在仓库中维护项目级上下文，例如：

docs/
├── architecture.md
├── coding-style.md
├── commands.md
└── security-rules.md

规则文件至少说明：

• 项目技术栈与目录职责
• 编码和命名规范
• 测试、构建与检查命令
• 禁止修改的目录
• 不允许新增的依赖类型
• 数据库和权限操作的审批要求

大型任务则采用“规划—执行—验证”三阶段：

1. 规划：只分析影响范围，不修改代码

2. 执行：只处理确认过的文件

3. 验证：检查 Diff、运行测试、列出风险

上下文不是越多越好。把几十个无关目录全部交给模型，就像让维修人员读完整栋楼的施工资料，只为了换一个门锁：成本更高，注意力反而更分散。

七、用 API 自动生成审查建议

下面是一个最小 Python 示例。具体 SDK 参数、模型标识和接口地址，应以发布时的官方文档或所用服务商页面为准：

import os
from anthropic import Anthropic

client = Anthropic(
api_key=os.environ["ANTHROPIC_API_KEY"],
# 使用兼容服务时，按服务商文档配置 base_url
)

response = client.messages.create(
model=os.environ["CLAUDE_MODEL"],
max_tokens=1200,
system=(
"你是一名谨慎的编程助手。"
"修改代码前先给出计划，不确定时主动说明，"
"不虚构依赖或 API。"
),
messages=[
{
"role": "user",
"content": """
请审查下面的 Python 函数，找出潜在错误并给出最小修改方案：

def divide(a, b):
return a / b
""",
}
],
)

print(response.content[0].text)

以后可以把脚本扩展为：

• 读取测试失败日志
• 获取当前 Git Diff
• 提交相关文件片段
• 生成分级 Code Review 报告
• 将建议保存为 Markdown

但生产部署、数据库迁移、权限调整和密钥轮换等高风险动作，必须保留人工确认。AI 可以提出补丁，不应该默认获得生产环境的执行权。

如果你希望尝试脚本调用、批量 Code Review，或把模型接入自己的开发工具，可以前往 api.884819.xyz 查看当前支持的模型、接口格式和计费说明。8848AI 没有月租和订阅，采用按量付费；国产模型如 Deepseek、千问等可免费使用，平台也内置 AI 对话功能。

建议先用本文的最小示例测试连通性，再逐步增加上下文。第三方接口不等于 Anthropic 官方服务，实际模型名称、价格、数据处理方式及可用性，都应以平台页面为准。

发布时建议准备的 10 张截图

为了让教程更可信，建议配齐以下截图：

1. 客户端模型选择页面

2. API Key 与环境变量配置，密钥打码

3. 项目初始目录结构

4. Claude 输出实施计划的对话

5. 首次运行页面

6. 故障现象与分析过程

7. 修复前后的 Git Diff

8. 自动化测试结果

9. 调用量或费用记录，隐藏账号信息

10. 最终项目效果图

第三方平台截图必须标注平台名称，不要让读者误以为是 Anthropic 官方界面。

今天就能完成的五件事

不必从复杂产品开始。今天选一个小项目，然后完成：

1. 写出一份包含验收标准的需求说明

2. 只让 AI 实现一个功能

3. 在本地执行测试和构建命令

4. 人工查看 Git Diff

5. 提交一个可回滚的 Git 版本

最值得学习的不是某条“万能提示词”，而是如何定义任务、约束修改、验证结果和保留回滚路径。模型会不断更新，但这套工程方法不会很快过时。

当 AI 只能看到一个函数时，排错并不难；真正棘手的是一个包含几十个目录、数万行代码的真实仓库。下一篇我们将实测：如何让 Claude 理解大型项目，在不塞入整个代码库的前提下完成跨文件修改，并控制上下文成本与误改风险。

#Claude #AI编程 #代码审查 #人工智能 #8848AI #Prompt技巧 #开发者工具