构建复杂项目

目录

1. 在开始之前，先问自己三个问题

很多人一想到「用AI开发复杂项目」，第一个念头就是：打开ChatGPT或者Claude，开始问「帮我写一个XXX」。然后一周后，他们面对一堆碎片化的代码、互相矛盾的设计方案、跑不起来的环境，彻底凌乱。

AI很强，但它解决不了你自己都没想清楚的问题。在动手之前，你需要先回答这三个问题：

① 我要解决的核心问题是什么？ 不是「我要做一个xx平台」，而是「用户在什么场景下，有什么痛点，我的产品如何消除它」。能用一句话说清楚，才是真的想清楚了。

② 这个项目的「最小可验证版本」是什么？ 复杂项目的死法之一，是一开始就想做全套。先想清楚：哪个功能做完了，你就能验证核心假设？

③ 我愿意花多少时间在这上面？ AI加速了编码，但不等于零时间成本。一个复杂项目，你每天能投入几小时？算一下，决定边界。

这三个问题不是废话。它们是你后来所有决策的根基。每次你在项目里迷失方向，回到这三个问题，通常能把自己拉回来。

AI是一个极其高效的执行者，但它执行的方向，取决于你是否想清楚了要去哪里。

2. 规划：把「大事」拆成你能看懂的结构

复杂项目失控，往往从规划开始就埋下了祸根——或者根本就没规划。

我的做法是：用AI帮我做规划，但最终的架构决策必须我自己拍板。原因很简单：AI很乐于给你生成一个「完整方案」，但那个方案是基于你给它的上下文，而不是基于你真实的能力边界和项目现实。

规划分三层：

第一层：系统架构规划 画出整个系统的模块边界。不需要多精确，但每个模块的职责要清晰。这个阶段我会让AI帮我识别技术风险点——问它：「这个架构里最容易出问题的地方在哪里？」然后认真对待它的答案。

第二层：里程碑拆解 把项目拆成3～6个里程碑，每个里程碑结束时有一个「可演示的、真实可用的成果」。千万别让里程碑停留在「完成了某某模块的代码」这种层次——必须是用户或者你自己能实际体验到的功能。

第三层：当前sprint任务 只规划当前一周或两周的具体任务清单。不要规划得太远——越远的计划，和现实的偏差越大，你只会花时间更新计划而不是干活。

额外：维护一份「决策日志」 每次你做了重要的技术选型或产品决策，简单记下来：「为什么这样选，放弃了什么，当时的假设是什么」。两个月后，你会无数次感谢那时候的自己。

⚠️ 常见陷阱：不要让AI帮你「生成完整架构方案然后你去实现它」。应该是你先有个粗糙的想法，然后用AI来挑战它、补充它、找盲点。你得是驾驶员，不是乘客。

3. 执行：如何和AI高效协作而不是瞎转

很多人用AI写代码的姿势是：遇到问题就粘贴代码，问「为什么不行」，收到一大段修改建议，粘贴回去，然后发现出了新问题，重复。这个循环能让一个下午消失得无影无踪。

高效协作的核心原则是：给AI精准的上下文，问清晰的问题，拿到具体的交付物。

// 低效的问法：
"这段代码有问题，帮我修一下"

// 高效的问法：
"这是一个用户认证模块，使用 JWT + Redis 会话存储。
当用户从移动端同时发起两个请求时，偶发 401 错误。
以下是相关代码和错误日志 [粘贴]。
请分析可能的竞态条件，给出修复方案，
并解释你的推断依据。"

几个执行原则，帮你省掉大量来回：

• 一次只做一件事。 别让AI同时帮你设计数据库、写API、处理错误。拆开来，一个一个来，每步验证完再继续。
• 让AI解释，不只是生成。 当你不理解某段代码，让AI解释它的逻辑，而不是直接用。你不理解的代码，是你将来调试时的定时炸弹。
• 主动告诉AI你的约束。 比如「我们用的是Python 3.9，不能引入新的依赖库」「这段代码要在低内存环境下运行」。AI不知道你的约束，就会给出对它来说最优但对你来说不可用的方案。
• 保持会话的上下文连贯性。 在一个复杂模块上工作时，尽量在同一个会话里进行，让AI记住背景。不要每次开新对话然后重新解释一遍。
• 定期做「AI代码审查」。 每积累一定量代码，让AI以代码审查者的身份扫一遍，找潜在问题、反模式、安全漏洞。这是免费的code review。

4. 试错：失败是工作，不是失败

独立开发复杂项目，大量的时间会花在「这个方向不对，需要换一个」上。这不是浪费时间，这就是工作本身。

但有一种试错是高效的，有一种是低效的。

低效的试错：在一个大方向上沉没两周，发现方向错了，推倒重来，心态崩了。

高效的试错：快速做一个最小的实验，用最短的时间证明或证伪一个假设，然后继续。

遇到不确定的技术路线或产品方向，先问自己：我用2小时能不能做一个原型来测试这个假设？ 如果能，就做原型，不要空想。如果不能，把这个问题分解，找到可以快速验证的子问题。

在AI协作里，试错有个额外的技巧：让AI帮你列出当前方案的替代方案和各自的取舍。不要只走一条路，至少心里清楚有哪些路，以及换路的成本是多少。

好的工程师不是不犯错的人，而是犯错速度快、发现速度快、恢复速度快的人。

养成一个习惯：试错之前，先写下你的预期。「我预计这个方案能把响应时间从800ms降到200ms以内。」然后去验证。这个习惯会让你的试错从「随机乱试」变成「科学实验」，学习速度快很多。

5. 控制局面：不让项目变成一堆烂摊子

复杂项目最容易出现的失控状态，我把它叫做「技术债雪崩」：早期为了快速迭代积累了很多凑合的代码，某一天你发现改一个功能要牵动七个模块，每次修bug都会引入新bug，项目变成了你不敢碰的庞然大物。

防止失控，我有几条铁律：

• 每个模块要有明确的边界和接口。 哪怕只是口头约定，也要清楚：这个模块负责什么，不负责什么，对外暴露什么接口，不对外暴露什么。
• 不要让「临时方案」变成「永久方案」。 每一个你知道是凑合的地方，打上标记（TODO / FIXME），并定期处理。我的做法是每周五花一小时专门处理技术债。
• commit要小，message要有意义。 不要一次commit几百行代码、改了七件事、message写「fix stuff」。每个commit只做一件事，让你能随时回退到任意状态。
• 定期做「系统审视」。 每个里程碑结束后，花半天时间从全局视角看整个项目：哪些地方变得复杂了？哪些依赖关系变得混乱了？现在处理还来得及，再拖就晚了。
• 警惕AI生成的「巨型函数」。 AI很容易生成几百行的单个函数，里面什么都有，但模块化极差。你要主动要求它拆分，或者自己拆。

⚠️ 红线信号：当你发现自己「不敢修改某段代码」、「不知道这段代码在哪里被用到」、或者「添加新功能需要小心翼翼地测试一大堆不相关的功能」——这是系统开始失控的信号。需要立刻暂停新功能开发，进行一次专项的重构和梳理。

6. 逐步实现，逐步验证：永远保持可运行状态

这是我认为独立开发里最重要的原则，没有之一：任何时刻，你的项目必须处于可运行状态。

什么叫「逐步」？就是每一步都是在上一步可工作的基础上，做一个小的、可验证的增量。不存在「这几天代码都不能运行，等我把所有东西做完再说」这种状态。

// 错误的开发节奏：
第1天：设计整体架构
第2天：开始写核心模块
第3天：继续写，发现设计有问题
第4天：重新设计，重写核心模块
第5天：写完了，发现另一个模块的假设错了
第6天：沮丧

// 正确的开发节奏（增量式）：
第1天：让最简单的端到端流程跑通（哪怕是 hardcode 的数据）
第2天：把其中一个 hardcode 替换成真实逻辑，验证
第3天：继续替换下一个，验证
每一天：项目可运行，我知道今天加了什么，坏了什么

增量开发要配合「功能开关」（Feature Flag）的思维。每个新功能要能独立打开和关闭，不影响其他功能。这样你可以：

• 安全地合并半成品代码而不破坏主流程
• 快速回退有问题的功能而不影响整体
• 给自己或测试用户逐步开放新功能

跟AI合作时，这个原则同样适用。当你让AI帮你实现一个新功能，不要直接让它重写现有代码，而是让它在现有可运行基础上做最小的增量修改。这样出了问题，你知道是新加的部分导致的，而不是不知道在哪里。

💡 实用做法：每天开始工作前，先运行一遍项目，确认它是好的。每天结束工作时，再运行一遍，确认你今天的改动没有破坏现有功能。这个习惯能救你无数次。

7. 测试：不写测试的独立开发者会后悔

我知道，测试这个话题，很多独立开发者看到就想跳过。「我一个人，哪有时间写测试？」

但我要告诉你一个现实：当你用AI快速生成了大量代码，这些代码出问题的概率远超你自己写的代码，因为AI不了解你的系统全局，很容易在边界情况上犯错。没有测试的保护网，你的迭代速度会越来越慢，因为每次修改你都要手动验证一堆东西。

独立开发的测试策略，不需要追求100%覆盖率，要聪明地花时间：

优先测试核心业务逻辑 那些「如果这里坏了，整个产品就废了」的代码，一定要有测试。数据计算、权限判断、核心流程——这些先写。

测试边界情况，不是正常路径 正常情况往往自然能跑通。空输入、超大数值、并发、网络超时——这些AI生成的代码最容易在这里翻车。

让AI帮你生成测试 这是AI最擅长的事之一。把你的函数给AI，让它给你生成测试用例，尤其是边界情况。然后你来判断这些测试用例是否合理、是否覆盖了你担心的场景。

回归测试 = 你的安全网 每次你修复了一个bug，给那个bug写一个测试，确保它不会再出现。几个月后，这些测试会帮你挡掉无数次「修好这里，那里又坏了」的悲剧。

最后一点：测试也是一种文档。当你半年后回来看这段代码，测试告诉你「这个函数应该处理什么，不应该处理什么」，比注释还要可靠，因为它是可以运行的。

8. 心态：怎么不让自己崩溃

最后聊聊心态。这部分我觉得是最被低估的。

独立开发一个复杂项目，是一段很孤独的旅程。没有团队，没有PM催你，没有同事帮你debug，没有人告诉你「你做的是对的」。你唯一的燃料，是自己的判断力和内驱力。而这两样东西，会被消耗。

几件我坚持做的事，帮助我度过了很多黑暗时刻：

• 记录每天的进展，哪怕只是一行。 「今天把登录流程的错误处理重构了」——这一行字，在你觉得「我今天什么都没做」的夜晚，会是你的救命稻草。进展日志让你看到自己在移动，而不是原地踏步。
• 庆祝小的里程碑。 第一个API跑通了？值得喝杯好咖啡。用户注册流程完整跑了一遍？值得出去走走。别等到「做完了」再庆祝，因为复杂项目没有真正的做完，只有一个又一个的阶段完成。
• 设定「下班时间」。 独立开发最大的陷阱之一是无边界工作。没有了固定下班时间，你会一直处于焦虑状态，觉得「还有好多没做」。设定一个结束时间，到时间就停，效率反而更高。
• 找一个能说话的人。 不需要懂技术，但要能听你说「今天遇到了一个很难搞的问题，我是这么解决的」。说出来这个动作本身，能帮你整理思路，也能让你感到自己不是孤军奋战。
• 允许自己卡住。 有的问题，你想了三天没想通，睡一觉起来就通了。有的坑，你一头扎进去挣扎两小时，还不如出去跑个步回来重新看。大脑需要休息，允许它休息。

最容易崩的状态不是「太难了」，而是「不知道还有多远」。所以要给自己看得见、摸得着的下一步。

关于AI协作导致的特殊心态问题，我还要多说一句：用AI时很容易陷入一种「假进展」的感觉。AI给你生成了几百行代码，感觉做了很多，但其实你不理解那些代码，项目也并没有真正推进。这种感觉很好，但很危险。

真正的进展标准只有一个：有没有一个新的、可用的功能被用户（哪怕是你自己）实际用到了。代码量不是进展，已理解的代码才是。已理解的功能，才是已实现的功能。

当你感觉项目「快做不下去了」，停下来，列一张清单：到目前为止，我做成了哪些事？ 认真列，不要跳过，不要觉得「那些不算」。你会发现自己其实走了很远。然后继续。

写给每一个正在独自扛着复杂项目往前走的人。一个人 + AI + 清醒的头脑 = 你能做的比你想象的更大的事。