• <--关键区别：>
• <--硬模式：仓库干干净净，仿佛时间倒流。适合 "这轮 AI 生成得太烂了全部推倒重来">
• <--软模式：回退版本但不丢代码。适合 "方向对了但结构不对，我留着你写的东西，重新整理一下">

🚫 错误示例

✅ 正确示例

🧱 第二阶段：打地基

📌 明确项目边界和非功能需求

安全、性能、可用性、成本——这四个非功能需求如果写不清楚，就会导致后期返工。

🔒 锁定技术栈

不要追新。适合自己的才是最好的，

markdown 至于推荐组合，React + TypeScript + Tailwind CSS

说到选型原则。- 环境成熟、社区活跃 - 与 AI 的训练数据匹配度高

输出为 CLAUDE.md。

📐 让 AI 出轻量架构草案

让 AI 给出：

• 目录结构怎么分层？按理说，
• 模块？各自职责，说起来，
• 数据模型实体关系、字段定义？
• 组件树组件层级和复用关系？

无须 UML 图，只需轻量但完整即可。老实说，

📐 第三阶段：立规矩

📄 固化成文档

plaintext project-root/ ├── PRD.md ← 产品需求文档 ├── ARCH.md ← 程序架构文档 ├── DESIGN.md ← 设计文档 ├── Project.md ← 当前项目阶段文档 └── CLAUDE.md ← AI 的全局上下文/永久约束

为何这一步是关键？

现代 LLM Agent 在交互时会读取根目录下约定文档作为程序级上下文。这些文件提供的观点是，- 🌐 全局记忆 - 🔒 永久约束 - 📋 一致性保障

📦 定开发规范与参考资料文件夹

plaintext project-root/ └── docs/ └── references/ ├── api-example.md ← API 调用标准写法 ├── component-example.md← 组件标准写法 └── error-handling.md ← 错误处理标准写法

规范包括的观点是。- 命名约定、文件组织、注释风格 - 错误处理模式与上报方式 - API 接口规范

🛠️ 搞好 Git 与质量闸门

1️⃣ 每轮 AI 生成 → git add . && git commit -m "snapshot" 2️⃣ 不满意 → git reset --hard HEAD~1 或更精细如 git reset --soft 3️⃣ 每次 push 前 → lint + 类型检查 + 单元/集成测试通过

⚙️ 开发中的关键点

1️⃣ 小步提交 / 小回滚 bash 每完成一个小功能 → git add && git commit 若后续想撤销，只需一次 git reset --hard 即可。

2️⃣ 一次只让 AI 做一件事 ❌ “帮我加上登录、注册、个人中心和设置页面” ✅ “现在只做登录页面使用者名+密码登录，按 PRD 第 X 节验收标准”

3️⃣ 始终参考主要文档 每次 Prompt 都附带： markdown # 引用 PRD.md / ARCH.md / DESIGN.md 中已定义规则与样式。说起来，

4️⃣ 人工审核。不盲目信任 - 阅读主要原因，不必逐行阅读；说起来，关注关键方法与边界条件。- 执行代码并验证功能是否符合验收标准。

5️⃣ 持续更新 Project.md – 项目仪表盘

markdown Project.md: │ 当前阶段 ➜ 开发中 ➜ 已完成 ➜ 待评审 ➜ 已上线 …│ 功能列表 & 状态 ⬇️ │ 问题记录 & 接下来计划 ⬇️

五、 — 从屎山到黄金矿场

🎯 使用者痛点

🚀 实践建议

1. 提前规划再动手 – 别让“马上跑起来”冲昏头脑。
2. 保持小步迭代 – 一次只能解决一个具体需求。
3. 把握控制权 – 每一次生成都要有人审核，每条 commit 都是可追溯记录。
4. 自动化护航 – CI/CD 与 linting 为代码质量筑墙。
5. 持续反馈循环 – 将每次迭代结果及时反馈给团队与模型，让模型学习并改进。话说回来，

💡 最终一句话

掌握 Harness Engineering 的艺术。就是把A.I.能力变成A.I.工具；把A.I.产出转化为A.I.资产。只要有计划、有纪律、有工具，你就可以从 “AI 项目屎山” 躲过来而且把它变成真正可继续发展的价值来源。