cs-build-plan-app

根据想法规划应用

目前还没有代码。产出与 cs-build-import-codebase 相同的成果——核心功能 → 子功能 → 注释 → PRD → 任务——但依据的是一个人，而不是一个代码仓库。

分为两个阶段，中间设有一道关卡：

A. 思考（§1–§6）	对话进行，不写入任何内容	要完成的工作、用户旅程、各种用户、平台选择、难点及其解决方案、系统检查、v1 的范围
关卡	复述规划并获得明确同意	§6a
B. 编写（§7）	操作 CodeSpring	结构图和注释
C. 展示（§7a）	移交给 cs-build-ui-mockup	以最低成本发现分歧——修正内容会反馈到注释中
D. 编写指令（§8–§9）	只有在原型图获得认可后才进行	PRD，然后是任务

阶段 A 期间绝不写入 CodeSpring。 结构图一旦建好，修改成本很高，也会让人觉得自己已经对仍在讨论中的规划做出了承诺。阶段 A 就是用来讨论和质疑规划的。

这是 cs-build-import-codebase 的「尚无代码」对应方案，它会自行编写内容，而不是交接出去——那个技能的核心是读取代码仓库，而这里没有代码仓库。两者共用的是最终成果，而这部分已经抽取成通用内容：cs-build-import-codebase/references/target-map.md 中的节点模型和结构图规则、mindmap-structure.md 中的架构、commands.md 中的 CLI。使用这些内容；不要重新推导，也不要另建分支版本。

请阅读共享知识：codespring 技能中的 references/project-state.md（从任意阶段进入、三个阶段）、references/mindmap-structure.md（准确的节点／边架构）、references/prd-management.md、references/pitfalls.md。还要阅读 cs-build-import-codebase/references/target-map.md——节点模型、单句卡片规则和 4–8 个核心功能的上限在这里完全相同；不要重复陈述或重新推导。

然后阅读此技能自己的参考资料，它们介绍从零开始规划时的不同之处：

参考资料	阅读时机
references/elicitation.md	始终阅读。如何从一个人的脑海或录音中梳理出真正的应用需求。
references/platform-choice.md	指定技术栈之前阅读。根据能力选择 Mac、Web 还是 iOS——以及可能推翻这一选择的限制：负责人实际能构建和维护什么。 另需了解每种选择的代价。
references/hard-part-first.md	始终阅读。每个应用都有一个真正困难的部分；找到它，查找先例，并验证它。
references/data-and-shape.md	始终阅读，并在功能列表定稿之前明确参与者。五项无人提及的系统检查：他人发布的数据及其更新方式、跨产品共享的逻辑、各种用户及负责人的管理界面、数据存储在哪个数据库中，以及如何显示数据的时效性。
references/v1-scope.md	编写结构图之前阅读。如何缩减到一个循环，以及收入关卡。

统领一切的区别

导入代码库有事实依据。规划一个想法则没有。

有了代码库，即使判断错了也能查证——只要读一下文件。对于一个想法，一个自信满满却不符合对方脑中设想的计划，看起来和好计划毫无区别，直到他们看到成品。下面的每条规则都是为了避免这种情况。

第二点，也是更难的一点：

他们不知道自己不知道什么，也不知道自己需要什么。

非技术人员会根据自己见过的东西来描述应用。他们会要求做一个 Instagram 上见过的东西。你的工作不是照录他们的要求，也不是用自己的产品品味取代他们的想法，而是弄清楚他们想完成什么任务，然后带上他们无法提供的技术判断：什么能实现、什么成本高、什么已经存在，以及真正困难的部分是什么。他们决定做什么。你决定怎么做，也有责任告诉他们，要做的事会比他们想的更贵。

绝不要让规划会议只留下他们说过的话。 如果计划中没有任何他们自己写不出来的内容，那你做的是记录，而不是规划。

---

0. 检测项目当前所处阶段

和技能包里的其他技能一样，即使代码还不存在，你也未必是从零开始。

bash ../codespring/scripts/fetch-project.sh --out /tmp/cs-state   # read-only snapshot; prints the projectId
node ../codespring/scripts/state.mjs       /tmp/cs-state          # summary line + booleans and counts
node ../codespring/scripts/check-map.mjs   /tmp/cs-state          # map faults, before you add to them

从本地 .codespring/config.json 读取 projectId，并在任何写入操作前打印出来。

• 已存在地图 → 你是在扩展计划，而不是从头开始。运行 target-map.md 中的地图质量检查流程，按标题匹配，绝不要重新创建。
• 原来就有代码 → 用错了技能。转到 cs-build-import-codebase（如果不符合 project-state.md 中的五个问题中的任何一个，则转到 cs-build-audit-codebase）。来自 Lovable/Base44/v0 的半成品原型就是代码，即使用户称它“只是个模型”——在接受“还什么都没有”之前，先去查看。
• 尚未关联 → 进行关联。团队工作区项目必须先在网页应用中创建（pitfalls.md）。

⚠️ 为新项目指定独立目录——这是此技能独有的陷阱

技能包中的其他技能都在它们要映射的仓库中运行。你没有仓库，所以没有天然的项目目录——而你当前所在的目录往往是用户其他项目的父文件夹，其中已经有一个指向某个项目的 .codespring/config.json。

在那里运行 codespring init 会悄悄将该配置改为指向你的新项目，下一次在同级项目中启动的会话就会写入错误的位置。真实案例：一次规划任务在一个配置指向正在运行的 Mac 应用项目的文件夹中启动；只有在新的子文件夹中创建项目，才避免了劫持原项目。

codespring status                       # ALWAYS run first — whose project is this directory linked to?
mkdir -p "<AppName>" && cd "<AppName>"  # a new directory for the new project, even with no code in it
codespring project create --name "..." --description "..."
codespring init --project <newId> --force
codespring status                       # confirm the new id
cat ../.codespring/config.json          # confirm the PARENT's link is untouched

之后这个文件夹会成为仓库，因此这并不是一次性脚手架。绝不要在已关联到其他项目的目录中运行 init，也不要以为看起来空的文件夹就一定未关联——先检查。

1. 获取原始材料

输入是什么都可以：通话录音或转录稿、语音备忘录、Loom 视频、喜欢的应用截图、一段絮絮叨叨的话，或一次面对面交谈。

先通读所有内容，再提任何问题。 采访时问的问题如果录音里已经有答案，最容易让非技术人员失去信心。

提取，不要总结。 用对方自己的话，整理出：

• 面向谁，以及这个人想完成什么
• 对方描述过的每个屏幕、按钮、时刻或行为
• 对方提出的每项限制（平台、离线、价格、截止日期、受众年龄、无障碍）
• 每个参考应用或截图，以及具体来说，对方喜欢它的哪些方面
• 对方重复说过的内容——重复表明了他们真正重视什么
• 对方否定过的内容，以及原因

保留对方的措辞。 “五分钟是底线，少于这个时间就不值得” 应保留在记录中，最终也应写进 PRD；而 “可配置的会话时长” 则不应该。对方的话里包含着你可能不经意间遗漏的限制和原因。

完整方法（包括如何梳理销售电话，以及只有一段絮絮叨叨的语音备忘录时该怎么做）：references/elicitation.md。

1a. 先问对方是否已经决定用什么来构建——这件事要优先问

尽早问一个问题，因为答案可能让整个计划都行不通：

“你是否已经决定要用某个特定工具来构建？Base44、Lovable、v0、Replit、Bubble，还是其他工具？”

非技术人员往往已经订阅了某项服务，也学过一点某个工具；如果不问，他们通常不会主动提起——在他们看来，这不是需求，只是个细节。但这是硬性限制。 AI 网页应用构建工具只能生成网页应用，完全无法构建原生桌面或移动应用，因此，如果计划写的是“Mac 应用”，他们就无法按计划执行。

在这里，也就是 §1 中提问，而不是等到 §4 选择平台时再问——到那时，你已经推理出一个他们的工具可能无法实现的答案。

后续可以问：你已经决定要用它，还是只是已经付费了？、一年后由谁维护？ 然后将答案带入 §4，公开解决任何冲突（references/platform-choice.md — “优先于能力的限制”）。

2. 先弄清楚要完成的任务，再确定功能

先用一段话达成共识，并明确说出来：

谁会打开它，他们想完成什么，没有它时他们现在会怎么做，以及我们如何判断它是否有效？

如果你写不出这段话，说明你掌握的信息不足以制定计划，继续讨论功能也无济于事。回到 §1。

最后一部分并非装饰。“她每周完成三次训练” 是可衡量的结果；“她感到有人支持” 则不是，而且应用也无法以此为目标。

3. 和他们一起走查各个屏幕

这是需求挖掘的引擎，对那些无法描述软件的人也很有效：

闭上眼睛，想象你正在使用它。它就在你面前打开着。你首先看到什么？你会点击什么？然后会发生什么？

把它当作一段旅程，而不是功能列表来走查：打开 → 第一个屏幕 → 第一次点击 → 他们来这里要做的主要事情 → 完成 → 明天是什么让他们再次回来。非技术人员很擅长描述这个，却完全说不清“你的核心功能是什么”。

从侧边栏开始。 对桌面应用或 Web 应用来说，问一句 “侧边栏里有什么？” 几乎就能直接得出核心功能列表，而且这是用户能认出来的列表。就用这句话来问。

把侧边栏当作寻找核心功能的提示，而不是核心功能的定义。 核心功能是用户要做的一件大事。侧边栏只是列出大多数核心功能的地方，所以这个问题很有效——但有些应用有一个重要屏幕，用户需要按下按钮才能进入，而不是点击导航项；它仍然是核心功能。用户如何进入该屏幕，是记在笔记里的导航细节，而不是决定它是否应该出现在功能图上的依据。

真正重要的判断标准是：这是不是用户要做的一件大事？如果不把它列出来，是否会让构建内容的大部分被遗漏？ 两个答案都是肯定的 → 它就是核心功能，不论它是否在侧边栏里。

仍然以 4–8 项为目标（target-map.md）。如果按这个标准列出了十项，说明列表粒度太细，而不是不够诚实。

接着走查第二位用户——负责添加内容的人。 人们会从使用应用者的角度描述应用，却从不提是谁填入练习、课程、模板或项目。内容创作工具其实是第二个应用，在功能列表中却经常完全没有出现，尽管它通常占整个构建工作量的 30–50%。问问第一天的内容从何而来、谁会添加更多内容、内容是否因用户而异、由谁决定顺序，以及第二天会发生什么——这是应用规划中最常被跳过的问题。references/elicitation.md。

脚本、后续问题以及绝对不该问的问题：references/elicitation.md。

3a. 列出所有用户类型——包括所有者

在敲定功能列表之前就问这个问题，因为答案会为列表增加功能：

“使用这个应用的不同人群有哪些？他们各自能看到和做什么？谁负责管理？”

他们会描述一种用户。实际上通常有四五种：终端客户；经常无需登录就能收到输出的这些客户的客户；员工；合作伙伴；以及运营该应用的企业所有者。

几乎每个应用都需要一个供所有者使用的管理界面——查看注册用户、管理套餐和访问权限，以及编辑应用所依赖的数据。几乎每个项目在规划时都会漏掉这一点，而事后补上成本很高，因为它改变的是权限模型，而不只是增加一个屏幕。问清楚有哪些套餐或等级，以及每种套餐能解锁什么，因为这决定了权益控制只需要一个字段，还是需要整个子系统。还要明确说明安全规则：权限必须在数据库和服务器端强制执行，绝不能只在界面上执行——隐藏按钮不等于访问控制。

人们经常忘记的完整角色列表，以及仅所有者可访问的数据问题：references/data-and-shape.md §3。

4. 根据应用必须实现的功能选择平台

在最终确定功能列表之前就这样做，因为平台选择会影响哪些东西能构建。

依据能力做决定，而非偏好或潮流：

需求	对应平台
摄像头 + 实时本地机器学习、文件系统访问、后台运行／菜单栏、真正离线、繁重的本地计算	桌面端（Mac）
通过链接分享、注册转化漏斗、SEO、“直接发给对方就行”、从第一天起就跨平台	Web
确实以移动端为先——在健身房、在野外、出门在外时使用	移动端

iOS 几乎从来都不是 v1 的正确选择：审核延迟、Apple 抽成，以及年纪较大的用户群体大多更喜欢大屏幕。直截了当地说明这一点，并说明原因。

然后把选择带来的后果明确说出来，因为这些问题以后都会带来麻烦：签名和公证、产品如何分发、支付如何运作、“离线”是否名副其实。完整的决策表及各选项的后果：references/platform-choice.md。

然后提出一个足以推翻以上所有判断的问题：他们实际上会用什么来构建，又由谁在你离开后维护？ 能力决定应用需要什么。这个问题决定对方能长期维护什么。如果他们坚持使用的工具无法实现能力所要求的平台——AI Web 应用构建器无法生成原生桌面应用——那么你们就面临真正的冲突，解决办法是沟通，而不是单方面悄悄推翻任何一方的决定。不要悄悄规划一个他们无法构建的平台，也不要因为他们使用的工具更方便，就悄悄放弃某项能力。把两种方案的代价都摆出来，让他们选择。references/platform-choice.md — “推翻能力判断的约束”。

4a. 沿用他们已有应用的技术栈

选定平台后，询问他们是否已经在该平台上有可运行的应用——可以是他们自己的，也可以是你为他们构建的。只询问，不要自行查找。 放在相邻文件夹中的代码库不一定就是参考项目——它可能是内部项目、已弃用项目，或是属于本项目刚刚排除的平台。阅读任何代码之前，先确认对方有意将其作为模板；一旦平台选择改变，就立即弃用它。

如果确认存在参考项目，就阅读其清单文件并保持一致：相同的语言版本、依赖、数据库层、设计系统目标，以及构建和发布脚本。

这不是偷懒，而是现成的最省成本的质量决策：

• 这套技术栈已经在该平台上成功发布过，包括那些繁琐环节——签名、公证、自动更新、崩溃报告。
• 设计系统已经存在，因此视觉语言一致，而且无需额外成本。
• 你正准备编写规范的组件可能已经实现。 在一次实际执行中，客户想要一个带玻璃模糊效果的面板和一张内嵌白色卡片；参考应用的设计系统目标中恰好已经包含这两个组件。有人查看之后，整项任务就省掉了。
• 同时维护两个应用的人只需熟悉一套技术栈。

因此：阅读参考应用的 Package.swift / package.json / 同类文件、设计系统文件夹和 scripts/。在路线图的技术栈节点上记录沿用的技术栈，并在备注中注明参考应用的名称，这样构建者就知道该从哪里借鉴模式，而不必从头发明。

如果没有参考应用，就选择一套成熟、常见的技术栈，并说明理由。

5. 找出难点，并找到已经解决它的人

每款应用都恰好有一件真正棘手的事。 其他部分都是屏幕、表单和列表。没有明确指出难点的计划就不是计划，而是愿望；直到第三周，构建过程才会发现问题。

明确说出难点，然后：

1. 在设计任何自定义方案之前，先搜索已有解决方案。 几乎可以肯定，已经有人解决了这个问题。使用 WebSearch/WebFetch；寻找仍在维护的库、平台原生框架（通常是最佳答案，也最容易被忽视）以及开源仓库。
2. 每次都检查许可证。 某个领域里最容易搜到的库，往往无法用于商业项目。这会让项目在后期付出高昂代价，甚至夭折。
3. 如果有平台原生框架，优先使用它——无需依赖项，无需考虑许可证，性能更好，而且能适应操作系统更新。
4. 把难点作为第一个任务，先做一个一次性验证，用真实输入证明它可行，再设计任何屏幕。

方法、附带实例的许可证陷阱，以及如何编写验证：references/hard-part-first.md。

5a. 执行系统检查——那些没人会问的问题

在 Think 阶段、确定 v1 范围和通过关卡之前，明确问出另外四个问题。没人会要求做这些，也没有用户能描述这些问题，但每一项作为决策的成本都很低，作为事后改造的成本却很高。第五个问题——用户是谁——已在 §3a 讨论，因为它会改变功能列表。

1. “这款应用依赖哪些由他人发布的数据？这些数据发生变化时会怎样？” 税率和关税、法定门槛、利率或福利标准、费率、邮资、汇率、合规限额、许可证费用、最低工资。如果存在这类数据：应将其存入数据库，而不是写进代码，并以记录形式保存适用起止日期；应用应根据所建模事件发生的日期解析当时适用的数值——包括已公布、但尚未生效的变更；每条已保存的数据都应记录生成它所用的版本；应用应知道数据何时过期并明确告知用户。不要假设存在 API——许多公共数据集并没有 API；抓取发布方网站比维护一张数据表更脆弱，因为抓取会因发布错误数字而失败，而不是停止工作。应规划一个诚实可行的方案：一张数据表、一个导入脚本、定期审查，以及一份记录数据来源的文档。另外，为负责人提供一个可编辑数据的界面，因为在你发布更新之前，他们就需要对已公布但尚未立法生效的变更进行建模。
2. “这款应用是否属于一系列共享同一套核心逻辑的产品？” 如果是，共享部分应当是每款产品都导入的一个程序包——绝不复制，也绝不重新实现。它必须是纯函数式的：不依赖数据库、网络、框架、时钟或随机数；所需的一切都通过参数传入。为它设置版本号，并按主题拆分成小文件，因为一个巨大的文件会让人直接复制函数，而不是导入程序包。两份副本迟早会悄无声息地出现分歧，最终导致业务中的两个部分为同一件事报出不同的数字。
3. “组织是否已有数据库？是否已有其他产品或其他人员在其中工作？” 默认每款产品使用单独的数据库，并让两者采用相同的所有权边界，以便日后合并。结构良好的两个数据库可以通过迁移合并；纠缠在一起的单个数据库则只能重建。
4. “用户是否需要了解数据有多新，或证明某个数字的来源？” 如果某项输出会影响财务、法律或医疗决策，就必须显示所用数据及其截止时间。绝不要声称数据是最新的，除非应用能够验证。应在估算值和假设出现的位置标明它们，并允许用户覆盖。

完整的推理过程和规则，以及每个问题的实例：references/data-and-shape.md。

6. 精简到真正可以发布的 v1

他们会描述成品。你的任务是打造能够端到端完成 §2 中任务的首个版本——一个完整、可运行、可销售的闭环。

• 闭环要完整。 用户打开应用，完成主要操作，并获得结果。不能有任何只完成一半的功能。
• 精简广度，不减深度。 五个完成度只有 60% 的功能，组成的是一个有缺陷的应用。一个完成度达到 100% 的功能，才是产品。
• 跟踪类功能不属于 v1。 任何价值在于“让用户输入自己做了什么”的功能，几乎没有吸引力，到了第二周就会失去价值。让应用替用户做事的功能，才会让人再次回来。参见 references/v1-scope.md——这是想法规划最常见的出错方式。
• **收入关卡：如果用户需要靠它赚钱，就要问“别人如何为此付费？”，并确保 v1 已经有答案。没有收款方式的 v1，无论多出色都无法产生收入；几乎每份计划都会漏掉这一点，因为没有人会对这个功能感到兴奋。
• 问清真正的成本是什么——通常是内容，而不是代码。 需要媒体库、数据集、练习目录或文档语料库的应用，通常 20% 是软件，80% 是获取内容。如果确实如此，现在就说明并规划好流程，因为这才是排期风险。references/v1-scope.md。

明确列出 v1 不包含什么，程度要和列出包含什么一样清楚——没有说出口的删减，之后会被当作未兑现的承诺。

6a. 关卡——复述计划，征得同意

目前还没有任何内容被写下来。没有明确的同意，不要继续。

按照他们在 §3 中描述的方式复述计划——“他们打开应用，看到 X，点击 Y，然后 Z 就会发生”——然后补上他们自己无法提供的信息：

1. 平台选择及理由（一句话，方便复述）。
2. 难点，以及解决它的具体方案——包括方案的许可证。
3. 每类用户，以及所有者能获得什么——管理界面、套餐，以及只有所有者才能编辑的内容（§3a）。
4. 他人发布的所有数据，它们存放在哪里、由谁更新、多久更新一次（§5a）——如果需要选择数据库，也要说明选择。
5. v1 包含什么，以及明确不包含什么。
6. 用户如何付费（如有营收需求）。

然后用以下原话提问：“我有哪些地方理解错了？还缺少什么？”

人们会纠正一个故事，却会照单全收一份功能列表。这是犯错成本最低的最后时刻——§7 之后，计划就会变成地图、笔记和任务，修改它就要付出实际工作。

在这里反复确认，直到问题解决。只有在他们表示同意后，才能继续。

7. 编写地图

机制与 cs-build-import-codebase §4 相同——节点模型、单句卡片规则和仅根节点可有备注的约束都来自 target-map.md。不要重新推导。

codespring mindmap set-info --title "..." --description "..."
codespring mindmap tech-stack --replace --add '[{"id":"tech-...","title":"...","description":"Frontend"}, ...]'
codespring mindmap features --add '[{"title":"Today","description":"..."}, ...]'   # CORE features; keep the returned ids
codespring feature create --parent <coreId> --title "..." --description "..."       # sub-features
codespring mindmap note <coreId> --title "How it works — X" --text "$(cat note.txt)"

codespring mindmap features --replace 并不会替换——它会追加并造成重复（pitfalls.md）。按标题比较，只添加缺少的内容。恢复方法：codespring feature delete <id> --yes。

在此路径中，备注就是全部交付物。 没有代码可供阅读时，备注是 PRD 生成器能获取的唯一上下文——这里的备注如果写得单薄，生成的 PRD 也会很单薄，而且没有代码仓库可供参考。每个核心功能的备注都应包含：

1. 此功能的作用，尽可能使用用户自己的措辞。
2. 界面和用户历程——用户会看到什么、点击什么，以及会获得什么。
3. 决策及其原因——平台、选用的库及其许可证、用通俗语言说明的数据模型，以及任何有意推迟的事项及其原因。
4. 属于此功能的 §5a 答案——会用到哪些已发布的数据，以及它们存放在哪里；与其他产品共享什么；谁可以查看和编辑每项内容；界面需要如何展示数据的时效性。这些信息在功能列表中不可见，却是 PRD 和任务构建出正确形态所必需的。
5. 明确不属于 v1 的内容，以免它们被悄悄实现。

生成任何 PRD 之前，先编写备注。

7a. 移交给 cs-build-ui-mockup——在 PRD 之前

不要根据没人看过的计划生成 PRD。 地图和备注已经通过文字达成一致，但光有文字还不够：人们会批准自己实际上并未理解的书面计划，因为文字会让双方以不同方式填补空白，而且都不会察觉。

运行 cs-build-ui-mockup。 它会根据这些备注生成一个可交互的临时模型，执行审查以暴露计划无法表达的问题——屏幕顺序、层级、位置，以及后来发现不完整的选项——并将所有修正写回备注和任务中。

一次实际运行中，一个已经通过关卡且看似完整的计划，在十分钟内就发现了 十一处需要修正的地方。这些问题在书面审查中一个都没有显现。

只有在审查改变了功能集时才回到这里。否则，流程继续：mockup → cs-build-create-prd → cs-build-create-tasks。

8. 验证

运行检查，不要靠目测：

bash ../codespring/scripts/fetch-project.sh --out /tmp/cs-verify
node ../codespring/scripts/check-map.mjs   /tmp/cs-verify --expect-core <the count you intended>

核心功能数量一致；没有被扁平化到顶层的子功能（使用 codespring feature update <subId> --parent <coreId> 重新设置父级）；没有重复标题；每个核心功能都有一条备注。非零退出码代表确实失败——先修复，再报告。然后提供项目链接 https://v2.codespring.app/project/<projectId>。

9. 移交

PRD → cs-build-create-prd（每个核心功能都生成 Both）。绝不要为没有备注的功能生成 PRD。 任务 → cs-build-create-tasks，并将 §5 中的 spike 设为任务 #1。 然后 → cs-build-feature。

10. 报告当前已有的内容

简短收尾，让用户清楚自己现在负责什么：项目链接、核心功能名称、每个功能都有备注，以及唯一的下一步操作——通常是 “任务 #1 是验证难点的 spike；先做这件事，再做其他事。”

---

优秀成果的标准

• 任务段落已经写好，并且在提及任何功能之前就已达成一致。
• 功能列表源于一次完整走查的用户旅程，而非头脑风暴，最终确定为 4–8 个用户能一眼认出的核心功能，可作为侧边栏项目。
• 平台是基于能力选定的，并且说明了相应影响，而不是默认选择或赶时髦。
• 难点已明确指出，有可查证的先例，且其许可证已核实，义务用一句话说明，并将其列为任务 #1，作为一次探索性验证。
• 在确定功能列表之前，已列出每一类用户；所有者有管理界面，并明确说明权限在服务器和数据库中强制执行。
• 已列出其他人发布的每一项数据，并以带日期的行保存，而不是写入代码；数据按所建模的日期解析，并有切实可行的更新计划——不假设一定存在 API。
• 如果同一逻辑在多个地方运行，它应是一个纯粹的、带版本的包，而不是另一份副本；数据库方案也经过了审慎决策，而非沿用旧方案。
• 新项目有了自己的目录，且没有覆盖任何同级项目的链接。
• 如果同一平台上已有成熟应用，就应沿用其技术栈和设计系统，而不是重新发明。
• v1 是一个完整闭环；如果用户需要通过它赚钱，v1 就应提供收款方式。
• 如果真正的成本在于内容而非代码，就要直言不讳，并建立相应流程。
• 笔记内容翔实——在这条路径上，它们是 PRD 能获得的唯一上下文。
• 过关之前，没有任何内容写入 CodeSpring；并且已将计划作为一个故事复述一遍，当面问出 “我有哪些地方理解错了？”。
• 计划包含用户自己无法提供的技术判断。如果只是把用户的话整理得更清楚，那就是听写。