AI 时代，程序员都应该有一个自己的软件项目
现在最危险的程序员，不是不会用 AI 的程序员，而是只会让 AI 帮自己写代码的程序员。
因为代码正在变便宜。
过去，一个程序员的熟练度很大程度体现在“能不能把功能写出来”。接口、页面、数据库表、脚本、部署配置，这些东西都需要时间慢慢堆。但今天，AI 已经能很快生成一堆看起来能跑的代码。它可以写 CRUD，可以补测试，可以解释报错，可以把一个想法拆成几个文件。
这当然是好事。但它也带来一个问题：如果程序员只是在需求后面接代码生成，那他的价值会被压得越来越薄。
AI 能帮你更快地产出代码，但它不会自动告诉你什么问题值得做，也不会替你承担一个项目烂掉之后的后果。真正的软件能力，从来不只是写代码，而是把一个模糊想法变成可以运行、可以维护、可以迭代的软件。
所以我的判断很简单：AI 时代，程序员都应该有一个自己的软件项目。
不是为了创业，不是为了包装简历，也不是为了在 GitHub 上摆一个好看的作品集。而是因为程序员需要一个属于自己的真实场地，持续训练问题感、工程判断、长期维护能力，以及更重要的：如何指挥 AI Agent 做软件。
个人项目不是三天写完的 demo
这里说的个人软件项目，不是跟着教程敲出来的 Todo App，也不是周末心血来潮做完后再也不打开的玩具。
它可以很小，但必须真实。
它可以是一个自己用的记账工具，一个 Obsidian 插件，一个管理家庭 NAS 的脚本，一个博客系统，一个命令行工具，一个小型 SaaS，也可以是某个工作流里的自动化工具。规模不重要，重要的是它真的被使用，真的会坏，真的会随着你的需求变化而变化。
真正有价值的个人项目，通常有几个特征：
- 你自己会长期使用。
- 它解决一个具体问题，而不是为了展示技术栈而存在。
- 它有真实输入和输出。
- 它会经历需求变化、代码腐化、依赖升级和重构。
- 它能沉淀成代码、文章、经验、工作流或工具。
很多程序员不缺学习材料，缺的是长期拥有一个问题。个人项目的价值就在这里：它不是一次性的练习题，而是一个会反复向你要答案的软件。
公司项目训练的是局部能力
在公司里，大部分程序员都不是完整的软件负责人。
需求可能来自产品，架构可能由技术负责人定，部署有运维或平台团队，测试有 QA，业务方向由老板和市场决定。程序员通常负责其中一段：把某个需求实现掉，把某个 bug 修掉，把某个接口接上。
这当然也是工程能力，但它不是完整的软件能力。
个人项目不一样。你必须自己回答一串没人替你回答的问题：
- 这个问题是不是真的值得解决？
- 第一版做到多小才够用？
- 数据应该怎么存？
- 需不需要登录、权限、备份和导出？
- 部署在哪里，成本多少？
- 出错了怎么知道，怎么恢复？
- 功能做歪了是重构，还是删掉？
- 半年后自己还能不能看懂这段代码？
这些问题听起来琐碎，但它们才是软件长期存在时真正会碰到的问题。
个人项目会逼着程序员从“功能实现者”变成“软件负责人”。这个身份变化，比多学一个框架更重要。
AI 让个人项目更容易开始
几年前，个人项目的门槛很高。
后端程序员可能卡在前端页面，前端程序员可能卡在后端接口，大家都会卡在部署、文档、测试、设计和各种莫名其妙的报错里。一个人做完整软件，时间成本很高。
现在不一样了。
AI 可以帮你补齐不熟悉的技术栈，可以生成第一版界面，可以解释错误日志，可以写脚手架，可以补测试，可以整理文档，也可以把一个大任务拆成小任务。
过去你可能因为“不熟 React”放弃一个工具，现在可以让 AI 帮你写出第一版。过去你可能因为不会部署卡住，现在可以让 AI 帮你查配置、读日志、修构建脚本。过去一个人很难同时照顾产品、前端、后端、测试和文档，现在至少可以把一部分执行压力交出去。
但这里有个关键边界：AI 降低的是执行成本，不是判断成本。
执行更便宜以后，判断反而更值钱。因为代码生成得越快，错误决策也会被更快地放大。一个方向错了的项目，AI 写得越勤快，垃圾代码堆得越快。
所以个人项目在 AI 时代更重要。它让你不只是“用 AI 写代码”，而是练习“用 AI 做软件”。
真正要练的不是 prompt，而是 harness
个人项目还有一个在 AI 时代才变得特别明显的价值：它是 AI Agent 工作流的试验场。
在公司项目里，你很难为了验证一个想法就推倒重构，也不能随便把不成熟的 Agent 流程接进生产代码。你不能今天让 Agent 大规模改目录结构，明天把 REST API 换成 tRPC，后天又让它重写测试体系。团队协作、生产稳定性、历史包袱和交付节奏，都会限制你。
但个人项目可以。
你可以今天用 Cursor，明天换 Codex；这周尝试让 Agent 自动补测试，下周尝试让它读 issue、拆任务、写 PR；一个模块写烂了，可以直接推倒重来；技术选型错了，可以迁移；工作流不稳定，可以换一套。
这种自由不是为了乱折腾，而是为了训练一套自己的 AI 软件开发方法。
很多人谈 AI 编程，只谈 prompt。但我的感觉是，真正拉开差距的不是 prompt，而是 harness。
这里的 harness，可以理解成一套验证和约束环境：测试、类型检查、lint、E2E、seed data、构建脚本、回归用例、截图验证、代码审查规则、发布流程。它的作用不是让 AI 写得更多，而是让你知道 AI 有没有写坏。
没有 harness 的 AI 编程，本质上还是靠感觉验收。Agent 说“我已经完成了”，你看了几眼代码，跑了一下页面，好像没问题，然后就合并。这在玩具 demo 里问题不大，但在真实项目里很危险。
个人项目可以让你一点点搭出自己的验收环境：
- 用单元测试锁住核心逻辑。
- 用集成测试验证接口和数据库。
- 用 E2E 测试覆盖关键用户路径。
- 用类型检查和 lint 卡住低级错误。
- 用固定 seed data 复现问题。
- 用构建和预览流程检查发布结果。
- 用 changelog 和 commit diff 审查行为边界。
到最后，你训练出来的不是“更会问 AI 问题”，而是“更会给 AI 设置边界”。
这件事会越来越值钱。因为很多人都会说“我会用 AI 写代码”，但真正稀缺的是：我知道怎么让 AI 在一个真实项目里持续、安全、可验证地改代码。
重构比从零生成更接近真实开发
让 AI 从零生成一个 demo，并不能很好地证明什么。
真实软件很少永远停在第一版。它会变脏，会有历史包袱，会有一开始偷懒留下的命名，会有临时加出来的功能，会有依赖升级带来的破坏，会有你三个月后自己也看不懂的代码。
这时候，个人项目就变成了更好的训练场。
你可以让 Agent 做更接近真实开发的事：
- 把一个页面拆成组件。
- 把散乱脚本整理成 CLI。
- 把本地 JSON 存储迁移到 SQLite。
- 把旧 API 封装成更稳定的 client。
- 给没有测试的模块补测试，再做重构。
- 把旧项目迁移到新的框架版本。
- 把重复逻辑抽成领域服务。
这些任务都比生成 demo 难。因为它们要求 Agent 理解上下文、保持行为不变、控制修改范围、跑测试、处理回归。
真正检验 AI 编程能力的，不是让它生成一个 Todo App，而是让它在一个已经变复杂、有历史包袱、有真实使用场景的项目里安全地改代码。
个人项目给了你这个机会。
不要一开始就做大
很多个人项目死掉，不是因为想法太小，而是因为一开始想得太大。
一上来就要做平台、做社区、做完整 SaaS、做全端、多租户、支付、权限、后台、数据分析，最后第一版永远做不完。
AI 会进一步放大这种冲动。因为它让你觉得很多东西都能快速生成，于是你很容易低估长期维护成本。
但个人项目最重要的不是第一版多完整，而是它能不能活下来。
我的建议是，第一版只做一个闭环：
- 一个明确问题。
- 一个核心用户，通常就是你自己。
- 一个最短路径。
- 一个能持续使用的数据模型。
- 一个最基础的验证方式。
不要为了热门技术硬凑需求，也不要为了简历把项目包装得过度复杂。个人项目最宝贵的地方，是它可以从很小的地方开始，然后随着真实使用慢慢长出来。
一开始就服务所有人的项目，最后往往谁也服务不好。先服务好自己，反而更容易做出真实东西。
个人项目是一块软件主权
AI 时代，程序员更需要一块自己的软件主权。
公司项目属于公司，业务方向不由你定，技术选择不完全由你定，节奏也不完全由你定。你当然能在里面成长，但你很难完全按照自己的判断去试验、推翻和重建。
个人项目不一样。
它是你可以长期拥有的东西。你可以在里面试新框架，试新数据库，试 Agent 工作流，试测试策略，试部署方式，试产品判断。你可以把一个错误决策完整走完，也可以把一个正确判断慢慢打磨成系统。
这比“学会某个工具”更重要。
工具会变，模型会变，框架会变，但一个程序员能不能持续发现问题、构造系统、维护软件、验证变更，这些能力不会过时。
AI 会让很多代码变得不值钱，但不会让真正的软件经验变得不值钱。
一个长期维护的个人项目，就是程序员给自己保留的一块真实战场。你在里面犯错、修 bug、做取舍、换技术栈、处理反馈，也在里面重新确认自己不是一个只会接需求和补全代码的人。
AI 时代，程序员更应该有一个自己的软件项目。不是因为每个人都要创业，而是因为每个人都需要一个地方，持续训练自己把想法变成软件的能力。