从需求发掘到AI辅助我做项目：我是如何用 AI 辅助自己把一个真实问题变成工具的
写作方向：偏方法论总结、辅以个人案例、整体采用真诚的结构化分享风格。
前言：我不是先想做项目，而是先被问题折磨了很久
大家好，我是 Samuel。这期视频我想借着我做的这个“SPT 现实主义数值范围生成器”，跟大家聊一件事：一个项目到底是怎么从“我总觉得这里不对劲”，一步一步变成真的能用、还能持续推进的东西的。
如果只看结果，这件事好像很容易被总结成一句话：我做了一个工具，专门用来辅助我维护离线塔科夫整合包里的现实主义数值。
但真实过程其实完全不是这样。它不是“我突然有了一个很厉害的想法”，也不是“我一开始就把整个系统都设计好了”。更接近事实的情况是：我先被这个问题折磨了很久，最后才意识到，哦，这已经不是普通的小麻烦了，这其实是个很明确的需求。
一开始，我只是想把自己的离线塔科夫体验调得更接近我理解中的“现实主义”体验。但真的开始维护整合包以后，问题一下子就变得很具体：塔科夫在更新，MOD 也在更新，不同 MOD 的数据结构还不统一；武器、附件、弹药、装备数量又很多，改完一轮还得再检查一轮；碰到一些特殊物品时，还不能直接套通用规则，只能单独处理。
这里其实可以配一段对比演示：没有这个生成器之前，我是怎么手动改数值、做补丁的；有了生成器之后，又是怎么通过几次点击把同样的事情跑完的。
这种事第一次做，你会觉得很正常；但做十次、二十次以后，你就会发现，它已经不只是工作量问题了。它会持续吃掉你的时间、注意力，甚至把你对项目本身的兴趣都磨掉。因为我真正想做的，其实是更好的游戏体验，而不是天天在一堆 JSON、规则同步和重复劳动里来回打转。
后来我才慢慢意识到：一个值得做的项目，往往不是从“我想做点什么厉害的”开始，而是从“我真的受不了再这样重复下去了”开始。
而 AI 在这个过程中，对我最大的帮助，也从来不是“替我凭空生成一个项目”。它更像一个放大器：帮我更快地整理问题、澄清需求、搭出原型、迭代结构，把原本模糊的想法放大成可以执行、可以修改、也可以验证的项目形态。
一、如何判断：这到底只是麻烦，还是一个真实需求？
现在大家都在聊 AI 辅助开发、聊 Vibe Coding。很多人看完都会有一种冲动：我是不是也该做点什么？
但真正让人卡住的，往往不是“不会做”，而是“不知道该做什么”。
我觉得这通常不是因为能力不够，而是因为大家总想先找到一个“足够宏大、足够新颖”的想法。可现实恰恰相反：真正能做起来的项目，往往不是来自最酷的点子，而是来自那些日常看起来很琐碎、却会反复出现、反复打断你节奏的问题。
那对我来说，一个问题是不是能被做成项目，至少可以从四个角度判断。
1. 它是否反复出现？
如果一件事你只做一次，那它可能不值得专门工具化；但如果你已经重复做了很多次，它大概率就不只是偶然工作，而是一个稳定存在的需求。
在维护整合包的时候，我就不断面对同一类事情：读取不同来源的物品模板、查找更新之后的版本差异、重复调整数值、进游戏检查输出结果、重复修改个别不适合通用规则的条目。它们不是一次性的，而是每次更新、扩展、测试时都会重新出现。
一旦某个动作开始高频重复，它就已经具备了被抽象和被自动化的前提。
2. 它是否容易出错？
还有一些事情，真正让人疲惫的不是工作量大，而是它过于依赖人工记忆和手工核对。你知道自己大概会做，但你也知道自己迟早会漏、会错、会改串。
像数值范围是否统一、字段有没有漏掉、物品类型是否正确，这种事如果一直靠人脑顶着，就迟早会出错。只要一个问题长期依赖手工复制、手工比对、手工确认，它就非常适合被程序接管。
3. 它是否正在吞掉你的主线目标？
这是我后来特别看重的一点。
我真正想做的是更稳定、更统一、更符合自己审美的“现实主义游戏体验”。但在没有这个工具之前，我常常被大量这样的底层维护工作拖住。注意力不是用在“体验应该变成什么样”，而是用在“这一项到底改过没有”“这个版本的结构和以前到底是不是一样”“这个装备到底改过什么来着？”。
当一个问题开始持续侵占你的主线目标时，它就已经不仅仅是技术细节，而是成为你的障碍。
4. 它是否可以被描述清楚？
最后一个判断标准是：你能不能把这个问题真正讲明白。
不是只停在“我觉得这事很烦”，而是能不能继续往下说：
- 我现在到底在处理什么东西？
- 我最后想要一个什么结果？
- 这中间有哪些地方不能乱来？
- 我怎么判断它算是真的做成了？
如果这些问题你已经能大致回答出来，哪怕还不够完整，它也已经很接近一个项目雏形了。
所以回过头看，我后来做的并不是“灵感驱动的酷项目”，而是把一类长期重复、容易出错、不断打断主线目标、并且已经可以被描述清楚的问题，正式接住了。
二、真正重要的，不是急着做工具，而是先把需求说清楚
到这里，问题其实就从“这个值不值得做”，变成了“那我到底该怎么开始”。
很多人一想到做项目，脑子里冒出来的话通常都差不多：
- 我想写个小工具试试
- 我想把这件事自动化一点
- 我想让整个流程更省事一些
这些想法当然没问题，我自己一开始也是这么想的。但问题在于，如果你只停在这里，其实还没有真正进入“做项目”的阶段。因为“想省事”“想方便一点”本质上还是感受，它还不是一个可以直接落地的问题。
我后来慢慢发现，真正关键的不是赶紧打开编辑器，而是先把那种模糊的“烦”拆开。到底是哪里烦？是数据太乱？是重复劳动太多？还是每次改完以后，根本不知道自己有没有改对？
这一步一旦想清楚，后面的事情就会顺很多。所以现在每次我有“要不要做个工具”的念头时，我都会先逼自己回答几个很朴素的问题。
1. 我现在到底在处理什么？
以我的现实主义数值生成器为例，我面对的并不是一个规整统一、拿来就能处理的数据源，而是来自多个 MOD 的物品模板，里面有武器、附件、弹药、装备，而且结构还不一样。
当你把这件事说清楚以后，很多原本模糊的问题就会自己冒出来：我要兼容哪些格式？哪些字段一定要读？哪些只是拿来辅助判断的？哪些东西最终可以留下，哪些必须过滤掉？
到这一步，需求就不再只是“我想省点事”，而是开始变成一个真正可以动手解决的问题。
2. 我最后到底想得到什么结果？
如果前一个问题是在确认你要处理什么，那这个问题就是在确认，你到底想把事情做成什么样。
对我来说，我想要的不是“把 JSON 读出来”这么简单，也不是“随便改一批数值”。我真正要的是一套能稳定进入整合包维护流程的输出：风格统一、结果可控，而且自己以后回头再看，也还能继续维护。
很多项目后来会越做越散，并不一定是技术不够，而是因为一开始根本没想清楚：自己最后到底要交付一个什么东西。
3. 哪些地方是不能乱来的？
我觉得这一步特别重要。因为很多时候，需求一旦说得太宽泛，项目就会越做越漂。
在这个项目里，边界其实很现实：数值不能为了“看起来更刺激”就乱改；特殊物品不能硬套通用规则；输出结构也不能今天能用、明天自己就不敢碰。
但这个边界，我也不是一开始就知道的。整个项目经历过几次重构，从python移植到C#是一次，感觉代码过于臃肿要求简化是一次，发现mod武器会出错后修不掉推倒重来是一次，每一次重构，都是在不断摸索“哪些地方是不能乱来的”这个问题。
也正是到这里，我才慢慢意识到：项目不是靠功能越堆越多做出来的，很多时候恰恰是靠你愿不愿意先把边界定清楚。
4. 我怎么知道自己是真的做对了？
这个问题听起来很朴素，但其实特别关键。
如果没有验证标准，你每次修改都只能靠感觉判断：这次好像行了，这次大概没坏，这次应该没影响别的部分。可一旦项目要长期使用，这种“应该”其实是很危险的。
所以我后来会特别在意几件事：同样的规则下，结果能不能尽量稳定复现；改完之后，有没有办法检查别的部分是不是被顺手带坏了；文档、规则和代码之间能不能互相对得上。
而当这些问题都能一条条回答出来以后，我才真正觉得，自己不是在“随便做个工具”，而是在把一个原本很模糊的麻烦，慢慢变成一个能落地、能维护、也能继续迭代的项目。
接下来的关键，就不是“要不要立刻开始写代码”，而是：怎么把已经说清楚的需求，继续推进成一个真的能跑起来的项目。
三、从需求到 AI 辅助项目：我是怎么一步步推进的？
前面说的，其实都还是在解决两件事：第一，确认这是不是一个真实需求；第二，把这个需求尽量说清楚。
但说清楚以后，新的问题马上就来了：那接下来到底怎么把它往前推进？
真正决定一个想法能不能变成项目的，往往不是灵感本身，而是你后面采用什么推进方式。对我自己来说，这个转化过程大致可以分成三步。
1. 需求精炼：做减法是艺术
很多人一开始最容易犯的错误，不是做得太少，而是想一口气做太多。尤其是在 AI 看起来什么都能帮你生成的时候，人会很自然地觉得：既然都开始做了，不如把所有想法一次性塞进去。
但我后来越来越相信，真正重要的不是“功能多不多”，而是第一步够不够稳。也就是说，你得先做减法，先问自己：如果我现在只能解决最核心的那一部分问题，我应该先做什么？哪些是必须的，哪些只是看起来很完整、但暂时并不重要？
这其实就是很典型的 MVP（最小可行性产品） 思路。不是一上来就做一个大而全的系统，而是先做出一个自己真的能用、能验证方向、能帮你省下时间的最小版本。
我自己的项目也不是一开始就长成现在这个样子的。最初只是想先把最核心的数值处理流程跑通，先让它能帮我减少最痛的那部分重复劳动。很多后来补上的东西——比如更完整的规则管理、交互界面、例外覆盖、测试和验证——其实都是在这个基础上慢慢长出来的。
2. 文档先行：先写 PRD 和 TRD，不要急着让 AI 写代码
这是我后来体感特别强的一点：不要一上来就让 AI 写代码，先让它帮你把文档写清楚。
因为代码写得再快，如果前面的需求、边界和目标没说清楚，后面大概率还是会返工。AI 的确能很快给你一版能跑的东西，但如果你给它的输入本身就很模糊，那它只会很快地把模糊放大。
所以我现在更倾向于先把两类文档整理出来：
- PRD（产品需求文档）：这个东西到底要解决什么问题，给谁用，核心价值是什么
- TRD（技术需求文档）：大概要怎么实现，输入输出是什么，边界在哪里，哪些地方容易出错
这么做的意义，不是把个人项目搞得特别“正式”，而是逼自己把脑子里的感觉落成文字。只要它能被写下来，它就更容易被讨论、被修改、也更容易被 AI 正确理解。
对我来说，这一步做得越清楚，后面开发就越顺。因为你交给 AI 的不再是一句“帮我写个程序”，而是一份已经有目标、有范围、有约束的任务说明。
3. 迭代开发：高频提交，小步快跑
真正进入开发阶段以后，我越来越不相信“大干一场，一次做完”这种节奏。对个人项目来说，更现实、也更稳的方式，反而是高频提交、小步快跑。
也就是说，每次只推进一个很小的问题：先把某个输入处理好，再把某段规则补上；先让核心流程能跑，再慢慢补界面、补例外机制、补验证和测试。每一步都尽量有一个明确结果，而不是把很多东西搅在一起一次性改完。
在这个过程中，我会尽量把自己的角色切换成两种身份：一半像产品经理，负责判断现在最该做什么、什么先不做；另一半像代码审查员，负责检查 AI 或我自己写出来的东西到底靠不靠谱，有没有跑偏，有没有把问题搞复杂。
对我来说，AI 最舒服的用法，不是把方向也一起交出去，而是让它帮我提速，而我自己始终负责判断、取舍和验收。只有这样，项目才不会失控，也更容易长期维护。
如果要把“从需求到 AI 辅助项目”的过程压缩成一句话，我会说：先做减法，再写清楚，最后小步快跑。 很多项目不是死在不会写，而是死在一开始做得太多、太快、太乱。
四、为什么“真实需求”比“热门创意”更适合个人项目？
把前面这几步真正走过一遍以后，我反而越来越确定一件事：对个人开发者来说，最值得做、也最容易做下去的项目，通常不是那些听起来最炫的，而是那些你自己真的在反复使用、反复碰到、反复想把它做好一点的东西。
这几年大家聊项目时，很容易被“创意”吸引。好像只有足够新、足够特别、足够像趋势风口的东西，才值得投入。
但我自己的体验刚好相反。真正适合长期做下去的项目，往往不是最热门的，而是最贴近你生活和工作流的。
原因其实很简单。
第一，你自己就是第一用户。你知道哪里最痛，哪里最值得优先解决，哪里其实只是看起来高级、但并不重要。你不需要额外做太多虚构式想象，因为你每天都在直接使用这个场景。
第二，真实需求能提供持续反馈。一个你自己会反复使用的项目，会不断把问题重新暴露给你。你会知道哪里顺手，哪里别扭，哪里还有空白。相比之下，很多“热门点子”在最初兴奋过去以后，很快就失去反馈来源，也就失去继续打磨的动力。
第三，真实需求能帮助你保持克制。你不会轻易把项目做成一个越来越大的空壳，因为你很清楚什么是必须的，什么是多余的。你做的不是“看起来功能很多”，而是“真的能用，并且越来越顺”。
这也是为什么我后来越来越相信：比起追逐一个听上去很厉害的创意，不如认真观察自己到底在反复为什么事情付出代价。
五、把需求变成项目时，我最看重的不是功能数量，而是闭环
而当你真的按“需求精炼—文档先行—迭代开发”这条路往前走时，很快就会发现：做个人项目，与其一开始追求功能多，不如先追求闭环完整。
所谓闭环，简单说就是：
- 问题从哪里进入
- 规则在哪里表达
- 程序如何执行
- 结果如何输出
- 最后怎么验证有没有跑偏
只要一个项目能够形成这样的闭环，它就已经不再是“零散脚本”了，而是一个真正有维护价值的系统雏形。
拿我自己的项目来说，这个闭环后来逐渐长成了比较清晰的结构：输入数据从固定目录进入，规则单独抽离，模板独立维护，核心生成流程负责处理和输出，界面层负责交互，测试和检查机制负责兜底。它未必完美，但至少每一层都在回答一个明确问题，而不是所有东西搅在一起。
我觉得这对个人项目尤其重要。因为一个人做项目时，最大的风险往往不是“不够努力”，而是“脑中太多东西同时打架”。而闭环的作用，就是帮你把这些混乱拆开，让每一层只承担自己该承担的职责。
当你意识到自己是在搭一个闭环，而不是在拼命堆功能时，很多决策都会变得更清楚：这个功能是不是现在必须做？这个逻辑应该放在哪里？这个问题应该通过规则解决，还是通过例外机制解决？这个结果有没有办法被验证？
这些问题一旦能被稳定回答，项目就会从“能跑”逐步进入“能维护、能迭代、能放心继续扩展”的状态。
结语
如果这期视频最后只能留下一句话给大家，我希望是这句：
很多值得做的项目，并不是从“我要做个很厉害的东西”开始的，而是从“这件事我真的受够了，我想认真把它解决掉”开始的。
对我来说，这个现实主义数值生成器就是这样来的。它不是某个突然冒出来的宏大创意，而是从长期重复、长期出错、长期消耗我精力的问题里，一点点长出来的。
而 AI 在这个过程中最有价值的地方，也不是替我凭空造一个项目，而是帮我把这些原本就存在的问题，更快地梳理清楚、写成文档、搭出原型，再通过一次次小步迭代，把它慢慢推进成一个真的能用的工具。
所以如果你也想开始做自己的项目，我觉得不一定非得先逼自己想一个多大、多新、多震撼的题目。很多时候，你真正应该先看的，是自己最近到底在被什么事情反复打断、反复消耗、反复折磨。
把那个问题找出来，再把它一点点说清楚、缩小、写下来、推进下去，项目往往就会自己长出来。
这大概就是我现在理解的“AI 辅助我做项目”：不是代替你思考，而是帮你把真实需求更快地落地。
如果一个项目最终真的帮你省下时间、减少了重复劳动、让你更接近自己真正想完成的目标，那它就已经很有价值了。
贡献者
SamuelNOTCuriousMeow