给大家分享两个在trae常用的个人规则和项目规则 一个是 敏捷开发5s

技巧分享
1

一、文档管理规范（核心基础）

1.1 文档创建时机

新项目开发启动时，必须优先创建「说明文档.md」，作为项目全生命周期唯一管理载体。

1.2 文档核心内容

需包含项目规划、实施方案、进度记录三大模块，且内容需明确、可落地（如进度需标注具体时间节点）。

1.3 文档更新要求

  • 每次重新打开项目前，必须先阅读「说明文档.md」，确认当前进度与要求后再启动开发；
  • 项目计划调整、进度节点变更时，需即时更新文档对应模块；
  • 每完成一项工作任务（如一个功能开发、一个 BUG 修复），需立即在文档进度记录中标记完成并补充结果说明。

二、开发流程规范（过程管控）

2.1 任务管理逻辑

采用（顺序化思考）分析需求，拆解为可执行的 ToDoList，明确任务优先级与依赖关系。

2.2 任务执行闭环

严格按 ToDoList 顺序执行，完成一项任务后，需在文档及任务清单中标记 “已完成”，确认无遗留问题后，再启动下一项任务，直至全量完成。

三、问题解决规范（技术支撑）

3.1 问题处理优先级

开发中遇到技术问题时，优先通过工具查找最新文档、代码示例，尝试解决问题。

3.2 官方文档依赖

若未解决问题，必须查找对应编程语言的官方文档（如 Python 查Python.org、Java 查 Oracle 官方文档），严禁自行编造代码或解决方案，确保技术方案的准确性与合规性。

四、执行约束规范（硬性要求）

4.1 三大 “绝不允许” 原则

  • 绝不允许项目延期：严格按文档规划的时间节点执行，提前识别风险并调整计划（需同步更新文档）；
  • 绝不允许超出计划：开发范围、资源投入需严格匹配文档中的项目规划，若需扩容需先更新规划并确认可行性，严禁无规划扩展；
  • 绝不允许出错：开发过程中需多轮自检（如代码编译检查、功能测试），若出现错误需立即暂停并按问题解决规范处理，修复后需验证无误再推进。

五、环境与输出规范（基础保障）

5.1 开发环境统一

固定使用 Mac 系统进行 TRAE 编程开发，确保环境一致性，避免跨系统兼容性问题。

5.2 代码输出标准

生成代码时，必须为所有函数添加函数级注释（需包含功能描述、参数说明、返回值类型及用途），提升代码可读性与可维护性。

2 个赞
给大家分享两个在trae常用的个人规则和项目规则 一个是 6A工作流执行规则
2

这个敏捷开发5s框架对于在 Trae 里做项目管理很有参考价值，尤其"说明文档.md"作为唯一管理载体这个思路——让 AI 在整个项目周期里都基于同一份文档跑，是避免上下文断裂最有效的方式。

想补充两点实际使用时容易遇到的问题：

一是"文档更新要求"这块，如果完全依赖人工维护，AI 在每次新会话开始时其实无法确认文档更新是否及时。建议加一条规则：每次启动开发前，AI 必须主动比对文档记录时间和 git 最后修改时间，发现不一致时先更新文档再继续。

二是关于"三大绝不允许"，对于 AI 辅助开发的场景，建议把"绝不允许出错"改成"允许在可控范围内试错"——因为 AI 生成代码本身就有概率需要迭代，完全不允许出错会导致 AI 在不确定时不敢主动行动，反而降低了效率。给 AI 设定一个"安全边界"（比如不直接操作线上数据库、不删除未提交的代码）比"不允许出错"更有实操价值。

1 个赞
3

这套规则的优点很明显：把“说明文档.md”放到了整个开发流程的中心，等于给项目加了一个稳定的外部记忆。

我补一个在实际使用中很容易被忽略的问题：文档不是建了就有价值，而是能不能持续保持“轻、准、最新”。

最常见的两个风险是：

  1. 一开始认真维护，后面任务一多就不更新了
  2. 什么都往里塞，最后文档越来越长，重新打开项目时根本没人愿意读

所以如果用这套方法，我建议给“说明文档.md”再加一个约束：

只保留三类高价值信息

  • 当前目标是什么
  • 现在做到哪一步
  • 下一步最先做什么

其他像历史讨论过程、尝试失败的细节、临时调研记录，最好下沉到附录或单独日志文件，不要把主文档变成流水账。

另外，4.1 里“绝不允许出错”这个原则我理解你的本意是强调质量，但落到 AI 协作里，可能更适合改成：
允许试错，但不允许带着未验证的结果继续推进。

因为开发过程中完全不出错几乎不现实，真正关键的是：

  • 错了能不能及时发现
  • 发现后能不能停下来修正
  • 修正后有没有把结论沉淀回文档

这样这套规则会更稳，也更适合长期项目。

2 个赞