dev-system-skill/软件开发要求.md

软件开发流程

当收到软件开发需求时，必须在项目根目录 doc 下完成项目流程文档：需求文档、设计文档、测试用例。

• 需求文档包括总体需求的精炼描述，以及分解后可以实现的需求点，每个需求点要有唯一编号。

• 设计文档应与需求文档一一对应，包括整体的框架设计以及重点设计和基本设计。框架设计主要描述项目或模块整体的结构和内部功能划分方法。重点设计主要是对核心业务、难点、复杂点、安全点的重点描述。基本设计是与需求点一一对应的实现方案，要有唯一编号且记录需求点对应关系。

• 如果 doc 下以有相关文档，就保持相同风格添加和修改。如果没有 doc 或者doc 下没有相关文档，就创建新的文档。

• 如果需求是项目级的完整需求，可以分模块分文档分版本描述。

• 如果需求是模块级的需求，可以独立一个文档或附加到已有文档。

精准修改

• 仅修改与当前任务直接相关的代码内容。
• 不顺手优化相邻代码、注释、排版格式。
• 不重构原本可以正常运行的代码模块。
• 严格匹配项目现有代码风格，保留原有编码习惯。
• 因本次修改产生的无效导入、废弃变量，可直接删除。
• 发现项目中原有的死代码、冗余内容，仅做文字提醒，不擅自删除。

编程规范

• 每个函数都要有中文注释, 包括功能说明、参数说明、返回值说明等,如果有注意事项,也要在注释中特别说明。
• 每次需求修改都要同时更新文档、代码、测试代码。

任务模式

通常有小任务和长任务两种开发模式。如果需求简单适用于小任务模式，如果需求量大适用于长任务模式，通常长任务开始前会告诉你这是一个长任务。

小任务要求

• 需求不确定时立即询问而非猜测。
• 存在歧义时，列出多种解释，不默默选定单一方案。
• 如果任务有明显更简单的做法，直接指出优化思路。
• 发现代码矛盾、逻辑不一致时及时暂停，请求信息澄清。

长任务要求

• 任务开始前先尽快确认所有模糊和冲突的点。

• 任务开始一段时间后才发现的问题可以按惯例和最优原则先执行，不要一直卡住。并输出分歧选择记录表。记录表内容包括问题、可选方案 A/B/C，当前默认选择了 X。

文档规范

• 生成 mermaid 流程图时注意中文和符号转义问题。不要使用 <-- 这种反向箭头，使用正向箭头替代。
• 生成 mermaid 时序图时实体只显示头部的方框，不要显示底部的方框。

代码审核

请查看当前 skill 根目录下代码审核.md 的要求。