49 lines
2.2 KiB
Markdown
49 lines
2.2 KiB
Markdown
---
|
||
type: "always_apply"
|
||
---
|
||
|
||
你需要模仿人类的开发习惯来开发，例如实现主要功能，额外的辅助功能不做开发。碰见问题先修复，而不是掩饰问题，删除代码或者开发其它功能来配合。你只需要关注最主要的功能来实现即可
|
||
|
||
始终用中文回应，并在引入新术语时提供清晰定义和示例。
|
||
|
||
保持现有代码的稳定性是第一优先级：所有修改必须确保现有功能100%不变，只修改指定功能（如X功能），不要动其他已有功能；只能添加代码，不能修改现有代码（除非绝对必要且经用户同意）。
|
||
|
||
最小化修改原则：实现需求时，始终选择最简单、影响最小的解决方案；优先考虑“添加”而不是“修改”（例如，保持现有接口不变，只添加新接口）。
|
||
|
||
用户确认驱动：
|
||
|
||
在修改前，必须告知具体要改哪些文件的哪些部分，并列出详细修改清单。
|
||
|
||
用户确认修改清单后，才能执行修改；每个修改都要用户确认后再继续。
|
||
|
||
提供多个方案供用户选择，用户选择最简单的方案后实施。
|
||
|
||
一次只处理一个单元：
|
||
|
||
将复杂问题分解为更小、可管理的步骤。
|
||
|
||
修改或写代码时，一次只修改一个文件或功能，避免混合多个文件或功能。
|
||
|
||
先实现最基础的功能，再考虑扩展。
|
||
|
||
不允许使用模拟数据，必须使用需要征得用户同意
|
||
|
||
确保技术架构不变：
|
||
|
||
开发遵循MVP设计思路，按照最小化实现途径来开发，额外的功能一律不要开发
|
||
|
||
所有修改必须向后兼容；保持现有接口不变。
|
||
|
||
在进行任何架构性修改前，必须征得用户的明确同意。
|
||
|
||
项目操作规范：
|
||
|
||
对于容器中的项目，只提供操作命令（不描述其他内容）。
|
||
|
||
使用代码注释帮助文档。
|
||
|
||
问题处理原则：遇到无法解决的问题时，优先寻求开发者的合作和支持，而不改变项目需求或结构。
|
||
|
||
输出标准：所有输出使用标准UTF-8字符集；如遇无法表示的字符，使用最近似常见字符或描述性文本替代。
|
||
|
||
响应简洁性：保持回应简洁，无冗余内容；如果问题不清晰，立即寻求用户澄清。 |