帮我改进提示词 # 项目开发总指令：THUDeepSeek ## 一、项目目标 我要你开发一个全新的 Win...

Prompt

帮我改进提示词 # 项目开发总指令：THUDeepSeek ## 一、项目目标 我要你开发一个全新的 Windows 便携式图形应用，项目名称为 **THUDeepSeek**，作者为 **htmsty**。 项目地址D:\2\program\codex\autoThuDeepSeekAPI\THUDeepSeek 项目目标是：参考工作区中现有的 `autoTHUDeepSeekAPI`，充分研究它的源代码、功能逻辑、配置方式和实际行为，在理解现有项目的基础上，重新设计并完整实现一个功能相近、性能更好、安全性更高、配置更灵活、用户体验更完善的新程序。 这不是简单修改原项目，也不是在原项目上打补丁，而是一个独立的新项目。 ### 最重要的开发规则 **必须严格遵守以下工作流程，未经我确认，不得擅自进入下一阶段。** - 第一阶段：检查和分析现有项目，整理需求，向我确认。 - 第二阶段：我回复“开动”后，只建立新项目目录并编写项目文档，完成后再次向我确认。 - 第三阶段：只有我再次明确确认开工后，才能开始实际程序开发。 - 第四阶段：实现、测试、打包、检查 Git 历史以及按授权发布到 GitHub。 不能跳过阶段，不能把一次“开动”理解为允许直接开始全部开发。 --- ## 二、第一阶段：研究现有项目并向我确认 收到本提示词后，**先不要编写代码、创建项目文件或修改现有项目**。 首先检查当前工作区，找到 `autoTHUDeepSeekAPI`，认真阅读其源代码、项目文档、依赖配置、构建脚本及其他能够帮助理解功能的文件。 如果没有找到该项目，不要自行假设它的实现，也不要根据项目名称编造分析结果。请明确告诉我，并说明需要我提供什么。 ### 需要调查的内容 1. 原程序使用的编程语言、图形界面框架、构建方式及主要依赖。 2. 原程序完整的功能清单、用户操作流程、配置项及异常处理。 3. 自动获取清华 MadModel API Token 的具体实现方式。 4. 原程序对 DSH、CC Switch 等目标软件的检测、配置和更新机制。 5. 文件路径发现、配置文件解析、备份、恢复和状态检测的具体逻辑。 6. 原程序的性能、体积、维护性、安全性和用户体验有哪些可以改进的地方。 7. 哪些功能需要保持原有行为，哪些地方值得重新设计。 8. 哪些实现细节存在技术风险、兼容性问题或尚未确定的前提。 要以实际读取到的代码和文件为依据。不要只看 README 就认定自己已经理解整个项目。 ### 第一阶段的输出 完成调查后，先向我提供一份需求确认报告，包含： - 对原程序的功能理解。 - 新项目的目标与范围。 - 拟保留、改进和新增的功能。 - 推荐的技术方案及其选择理由。 - 关键技术风险和待确认事项。 - 预计的项目目录结构。 - 需要我决定的问题，以及你建议采用的默认选项。 对于能够通过阅读源代码解决的问题，不要反过来让我解释。 对于确实需要我决定的关键问题，集中列出，避免频繁打断工作。 **报告完成后必须停下来，等待我明确回复“开动”。在收到这条指令之前，不得创建或修改任何项目文件。** --- ## 三、第二阶段：编写项目文档 只有当我在第一阶段报告之后明确回复“开动”，你才可以进入这一阶段。 这一阶段的任务是：在新建的项目目录中，建立完整、可执行、便于后续开发的项目文档。 此阶段只做项目初始化和文档编写，**不得开始实现程序功能，不得为了方便提前编写正式业务代码**。 ### 项目目录要求 项目名称：`THUDeepSeek` 作者：`htmsty` 在工作区中新建一个独立的项目文件夹，所有新项目的源代码、文档、测试、构建配置和其他项目文件都存放在这个文件夹中。 禁止将新项目文件散落在工作区根目录，也禁止直接修改原有 `autoTHUDeepSeekAPI`。 目录命名、模块布局和语言生态应根据第一阶段确定的技术方案设计，不要在没有理由的情况下强行套用某个固定框架。 ### 必须编写的文档 至少包含以下内容： 1. `README.md` - 项目简介、核心功能、技术特点和使用场景。 - 开发环境、构建方式、运行方式和打包方式。 - 用户配置说明、隐私说明、常见问题及故障排查。 2. `docs/REQUIREMENTS.md` - 详细需求规格。 - 功能清单、配置项、输入输出、异常情况和验收标准。 - 标明必须实现、可选实现以及暂不实现的内容。 3. `docs/ARCHITECTURE.md` - 总体架构、模块职责和模块间的交互关系。 - API 认证、目标程序适配、配置管理、备份恢复、图形界面等部分的设计。 - 关键技术选择和替代方案的比较。 4. `docs/IMPLEMENTATION_PLAN.md` - 开发阶段划分。 - 每个模块的实施顺序、依赖关系和完成条件。 - 里程碑、风险及回归测试安排。 5. `docs/SECURITY.md` - 账号密码和 API Token 的生命周期。 - 敏感数据存储、日志脱敏、文件权限、备份保护和 Git 排除策略。 - 登录失败、Token 失效、认证服务异常等情况下的处理。 - 如何避免把真实凭据、个人信息和私人配置提交到 GitHub。 6. `docs/TESTING.md` - 单元测试、集成测试、兼容性测试和打包验收方案。 - 认证流程、路径探测、配置写入、备份和恢复等关键功能的测试用例。 - Windows 实际运行和便携部署的验收标准。 7. `docs/DECISIONS.md` - 记录关键技术决策、选择原因、已知限制以及后续需要重新评估的问题。 可以根据项目实际需要补充其他文档，但不要为了凑数量创建没有实质内容的文件。 所有文档必须彼此一致，不允许需求文档写一种行为、架构文档设计另一种行为、实施计划又采用第三种行为。 技术方案尚未验证的地方应明确标记为待验证，不能伪装成已经实现或确认可用。 ### 第二阶段完成条件 完成项目目录及上述文档后，请向我提交： - 创建的文件和目录清单。 - 每份文档的主要内容摘要。 - 已确定的技术方案。 - 尚未解决的风险和问题。 - 可以量化的项目验收标准。 - Git 初始化及 GitHub 发布的建议方案。 然后再次停下来，等待我的第二次明确确认。 **必须等我明确回复“确认开工”“开始实现”或意思明确的同等指令后，才能进入实际开发。** 如果我要求修改文档，先修改文档并重新向我确认；不能因为已经写好文档就自动开始编程。 --- ## 四、第三阶段：实现完整程序 收到第二次确认后，才开始正式开发。 ### 1. 总体要求 实现一个真正可运行、可测试、可打包的 Windows 图形应用，而不是只有界面的演示程序，也不是大量空函数组成的项目骨架。 遵循第二阶段确认的需求和架构。如果开发中发现必须修改方案的重大问题，应先清楚说明原因、影响及建议，再按照我的决定调整。 开发时保持项目整洁，合理划分模块，避免把所有逻辑写进一个主文件。 优先考虑： - 程序运行稳定。 - 启动快、响应及时、内存占用合理。 - 最终发布体积尽可能小。 - 配置、认证、文件操作与图形界面相互解耦。 - 错误信息清楚，便于用户自行排查。 - 对不同版本的目标程序具有良好的兼容性。 - 代码可维护、可测试，关键逻辑有必要的注释。 性能优化必须以实际测量和可验证的结果为依据，不要仅仅因为使用了某种语言或框架，就声称程序更快或更小。 ### 2. API Token 的自动获取 实现程序最核心的功能：让用户在程序内部配置清华 MadModel 账号和密码，由程序在用户授权的前提下自动完成认证并取得 API Token。 用户不应该再被要求手动打开网页、登录网页、寻找 Token、复制 Token，再粘贴到本程序中。 认证流程应尽可能自动化，并具有清晰的进度、成功状态和失败原因提示。 具体的认证方式必须以实际调查得到的接口、认证机制和当前可用条件为依据。优先使用官方支持的认证接口或其他明确授权的方式。 不得凭空捏造 API 接口、请求参数或响应格式；不得把无法验证的模拟认证当成真实实现。不得绕过验证码、多因素认证、访问控制或其他安全机制。 如果当前认证流程确实依赖浏览器交互、暂时不存在可验证的无浏览器认证方式，或者服务端机制发生变化，应明确说明限制，并提出可行替代方案，不得声称已经实现无人值守认证。 ### 3. 账号密码与 Token 安全 账号、密码和 Token 都属于敏感数据。 必须满足以下要求： - 密码和 Token 不得硬编码在源代码中。 - 不得在普通运行日志、调试日志、错误提示或崩溃报告中泄露密码和 Token。 - 不得将真实凭据写入 README、测试样例、截图或演示配置。 - 尽可能采用 Windows 系统凭据保护能力；确实不能使用时，应在文档中说明风险和替代方案。 - 默认不长期保存账号密码；如确有记住登录的需求，必须设计独立、明确的用户选项。 - 清理不再需要的敏感数据副本，并谨慎处理备份、临时文件和异常退出。 - 不得将用户凭据发送到认证流程以外的第三方服务。 - 所有网络请求应具有合理的超时、错误处理和必要的重试限制。 安全措施必须真正落实到代码中，而不是只写在文档里。 --- ## 五、必须支持的目标软件及原有功能 以下是明确提出的功能要求。第一阶段仍需结合原项目源码，补齐原有功能和兼容细节。 ### 1. DSH 凭据配置 能够检测并配置 DSH 的以下凭据： - 键名：`MADMODEL_API_KEY` - 值：通过程序认证流程获取的 MadModel API Token。 用户可以单独关闭这项写入功能。关闭后不得修改对应的目标配置。 应验证配置写入结果，并能识别目标配置已经是最新状态、缺失或需要修复等情况。 ### 2. DSH 的 LLM-Pi-AI Provider 支持在 DSH 相关配置中设置 Provider： - 配置路径对应的标识：`llm-pi-ai.providers.madmodel` - 展示名称：`DeepSeek (THU)` - `baseURL`：`https://madmodel.cs.tsinghua.edu.cn/v1` 应研究原项目以及目标软件实际使用的配置格式，确保最终写入的数据结构和字段符合目标软件的真实要求，不要仅仅依据上述点分隔标识猜测配置文件结构。 这项功能应能够单独关闭。 ### 3. CC Switch 供应商配置 支持创建、更新和检测以下供应商卡片： - 供应商标识：`deepseek-thu` - 显示名称：`DeepSeek (THU)` - `apiFormat`：`openai_chat` 需要兼容已有的同站点旧卡片，在不误删其他供应商或无关数据的前提下，正确刷新或更新相关配置。 这项功能也应当可以单独关闭。 ### 4. 激活当前供应商与代理路由 保留 `activate: true` 对应的行为： 默认启用激活功能，并允许用户在设置中关闭。 启用时，应根据目标软件的真实配置机制，将当前供应商及相关代理路由指向 `DeepSeek (THU)`；关闭时不得擅自修改用户当前使用的供应商或路由。 必须先弄清当前供应商、路由和激活状态之间的真实关系，避免因错误写入而使其他供应商不可用。 ### 5. 自动探测路径与手动配置 支持自动检测所有相关目标程序的安装位置、配置目录和配置文件路径。 同时，用户必须能够手动指定或修正这些路径。 路径探测需要考虑： - 默认安装位置。 - 用户目录和常见自定义安装位置。 - 不同安装方式造成的目录差异。 - 目标软件未安装、配置不存在、路径无权限访问等情况。 - 路径中包含空格、非英文字符等情况。 - 手动指定路径与自动检测结果不一致的情况。 探测规则应尽量准确，并提供可理解的检测结果，不能只依赖少数固定路径。 不能将不可靠的模糊匹配结果直接用于覆盖重要配置。发现多个候选路径时，应进行验证，并在无法判断时提示用户选择。 ### 6. 修改前备份与一键恢复 任何目标配置的首次修改，都必须先备份。 具体要求： - 备份原始文件和足以恢复其原始状态的信息。 - 明确记录备份对应的路径、时间和修改对象。 - 修改前先确认备份成功；备份失败时不得继续执行破坏性操作。 - 后续修改也要保留足够的恢复能力，不能因为已经存在旧备份就丢失重要版本。 - 提供清晰易用的一键恢复功能。 - 恢复操作应尽量精确地还原程序管理过的变更，防止覆盖用户后来进行的无关修改。 - 正确处理原文件不存在、恢复文件损坏、目标文件正被占用及权限不足等情况。 备份可能包含密码、Token 或其他敏感数据，因此必须纳入隐私数据保护方案。 --- ## 六、进一步优化与可配置性 除以上明确功能之外，结合原项目实际实现，识别可以改进的地方。 新增功能不能只为了数量，应当实际改善使用体验、安全性、维护性或稳定性。 重点考虑以下方面： ### 用户体验 - 清晰直观的 Windows 图形界面。 - 账号配置、连接状态、Token 获取、目标探测、配置写入和恢复等操作有明确的状态显示。 - 失败时展示具体、可理解的原因。 - 提供配置检测和操作结果核验。 - 对涉及覆盖、清理或恢复的重要操作进行明确提示。 - 避免需要用户频繁进入配置文件手工处理的问题。 ### 配置选项 在保留原有功能的基础上，尽量让用户能够独立控制各项行为，例如： - 每个目标软件的配置写入开关。 - 当前供应商及代理路由激活开关。 - 目标程序自动探测和手动指定路径。 - 是否记住账号或登录状态。 - 备份策略和恢复行为。 - 日志详细程度及敏感信息保护选项。 - 启动行为、更新检测和其他经过实际评估有价值的选项。 配置选项应具有明确的默认值、合理的持久化方式和一致的行为。不要引入大量重复、互相冲突或用户难以理解的开关。 ### 性能和程序体积 以 Windows 便携程序为目标，在不牺牲必要稳定性、安全性和功能完整性的前提下，优化： - 启动时间。 - 内存占用。 - 不必要的依赖。 - 最终打包体积。 - 重复文件和无用资源。 - 重复网络请求与重复文件扫描。 - 不必要的后台任务。 优先采用经过评估、适合项目需求的轻量方案。 如果某项优化只能带来很小收益，却会明显增加维护难度，应优先考虑长期可维护性。 必须在开发文档中记录实际采用的优化方法。最终报告中应尽可能提供真实的构建体积、启动测试和内存测试数据；无法测量的指标要明确说明。 --- ## 七、便携化与发布要求 最终程序应当适合放在普通文件夹或移动存储设备中运行，尽量不要求用户安装完整开发环境。 需要评估并实现： - 合理的发布目录结构。 - 可复现的 Windows 构建和打包流程。 - 首次运行与后续运行的行为差异。 - 配置和备份文件的保存位置。 - 权限不足、缺失依赖及升级场景。 - 软件目录不可写时的处理方式。 - 在干净环境中验证启动和核心功能。 便携性不能以随意将敏感凭据保存在程序目录为代价。需要明确区分程序文件、普通配置、敏感数据和备份数据。 打包完成后，实际运行发布版本，而不应仅以 IDE 中能运行作为交付完成的依据。 --- ## 八、隐私目录与 Git 管理 整个开发过程都必须正确处理 Git。 ### 目录和敏感文件 项目私密数据集中管理，统一放在 `private/` 目录下，并默认通过 `.gitignore` 排除。 如果技术架构要求运行数据、用户凭据或真实配置放在其他位置，也必须有相应的排除和保护措施，不能为了满足目录名称而牺牲安全性。 仓库中可以包含必要的示例配置、占位符和不含真实凭据的测试数据，但不能包含真实账号、密码、Token、个人数据、生产配置副本或含敏感信息的备份。 ### 提交前检查 - 检查 `.gitignore` 是否确实生效。 - 在每次提交前检查暂存区。 - 检查提交差异中是否包含敏感数据。 - 确保私密目录里的文件没有被追踪。 - 对发现的泄露风险立即停止发布并进行处理。 仅仅把 `private/` 写进 `.gitignore` 并不能自动保证此前已追踪的文件不再被提交，必须检查实际 Git 状态。 任何真实秘密一旦被提交到 Git 历史中，都不能简单地声称删除当前文件就已经解决问题。 ### Git 与 GitHub 建立独立、清晰的 Git 仓库，项目的源代码和文档都应纳入合理的版本管理。 提交历史应便于理解，尽量按照功能模块和开发阶段组织提交，避免只有一个包含全部内容的大型提交。 我要求最终将项目提交到 GitHub，但必须如实处理以下事项： - 优先使用已经可用且经过授权的 GitHub 认证方式。 - 不得将 GitHub Token 或其他凭据写入源代码。 - 远程仓库地址、账号和公开范围不明确时，先向我确认。 - 不得谎称已经创建仓库、推送代码或发布版本。 - 若当前环境缺少 GitHub 访问权限或认证条件，应完成可完成的本地工作，并准确说明阻碍。 - 向 GitHub 推送前，必须确认待推送内容中没有敏感文件。 - 如果需要创建公开仓库，或者发布会使源代码公开的版本，应先明确确认仓库可见性。 最终应提供实际仓库地址、提交记录或可核验的发布结果；如果无法推送，则提供准确的本地 Git 状态及未完成原因。 --- ## 九、测试与质量标准 开发完成不能只以“程序可以打开”为标准。 至少验证以下情况： 1. API 认证成功和失败。 2. Token 缺失、过期或服务端返回异常。 3. 目标软件存在、缺失和无法检测。 4. 自动路径检测和手动路径配置。 5. 三类目标配置分别启用和关闭。 6. 激活功能启用和关闭时的实际差异。 7. 同站点旧供应商卡片更新。 8. 首次修改备份及一键恢复。 9. 配置文件损坏、权限不足和文件被占用。 10. 重复运行、重复配置和重复恢复。 11. 网络中断、请求超时和异常退出。 12. 便携发布版在干净 Windows 环境中的运行情况。 13. Git 仓库中是否意外包含敏感文件。 能编写自动化测试的部分应尽量自动化。 没有真实账号或测试环境时，不得伪称真实认证、线上集成或跨环境兼容性测试已经通过。应将可自动验证的部分与必须由用户完成的验证清楚区分。 --- ## 十、最终交付标准 只有同时满足以下要求，才可以宣布项目完成： - 新项目与原项目完全分离。 - 核心功能有实际实现，而不是空壳或占位代码。 - 账号认证和 Token 获取逻辑经过真实条件下的验证，或明确标记仍待验证的限制。 - DSH 凭据、DSH Provider 和 CC Switch 供应商等目标适配功能均符合需求。 - 每项配置写入功能都可以单独启用或关闭。 - 自动探测、手动指定、备份和恢复可用。 - 重要的错误情况得到处理。 - 测试结果有记录，未通过的项目明确列出。 - Windows 便携版已完成实际构建与运行验证。 - 项目文档完整且与实际实现一致。 - Git 历史合理，仓库不包含敏感信息。 - GitHub 发布状态真实可核验，未完成的工作如实说明。 ### 最终报告格式 项目完成后，向我提供一份最终交付报告，至少包括： 1. 已完成功能与需求对应情况。 2. 项目文件结构。 3. 技术栈及关键架构。 4. 构建命令与实际构建结果。 5. 测试项目、测试结果和未解决问题。 6. 便携程序的位置、实际大小和运行方式。 7. 性能优化结果及其测量依据。 8. Git 仓库状态、关键提交记录和 GitHub 地址。 9. 配置、备份、恢复和隐私数据的使用说明。 10. 用户需要知道的已知限制与后续改进建议。 不要为了让报告显得完整而编造测试数据、性能结果、远程仓库地址或尚未实现的功能。 --- ## 十一、执行纪律 始终遵守以下原则： - 先研究，后设计，再实施。 - 先确认，再进入下一阶段。 - 不修改原项目，所有新文件放在独立项目目录。 - 优先理解现有实现，不凭空猜测。 - 不用虚假实现冒充完整功能。 - 不为了追求速度跳过安全检查和关键测试。 - 不擅自删除用户数据或覆盖无关配置。 - 遇到重大技术障碍时，说明事实、影响和建议。 - 对可以独立推进的工作，尽量自行完成，不要反复询问已经明确的要求。 - 每一阶段完成后提供真实、具体的结果。 **现在开始执行第一阶段：检查当前工作区中的 `autoTHUDeepSeekAPI`，完成研究并向我提交需求确认报告。此阶段只能分析和汇报，不得创建项目文件、修改现有文件或开始编码。报告提交后立即停止，等待我回复“开动”。**