在AI时代，如何从0接手一个项目？

在AI时代，如何从0接手一个项目？

引言

我是一个对前沿科技非常感兴趣的人。根据"技术采用生命周期"，我应该算是"早期使用者"。

（👆这张图有一个错误："早期采用者"和"早期大众"之间应该隔着一个"认知鸿沟"，如第一张图所示。这张图画错了。）

从2022年11月下旬的ChatGPT 3.5发布到现在，我应该是见证了AI在短短不到4年的时间里一步一步发展到现在的样子的。因为我是计算机科学专业的，所以似乎这一切都变成了理所当然。从我在校期间的AI难堪大用，到现在刚毕业就碰上AI正逐步接手软件工程的大势所趋，在绝望之余也同时发现了一个问题------网上那些搞科普的、分享AI编程技巧的自媒体，他们写的文章都是脱离实际的。这其中甚至不乏那些互联网大厂的技术团队，也包括本社区（TRAE官方社区）的某些个人开发者。

虽然我在今年6月才即将脱离应届生身份、加入正式的程序员岗位也才一个月，但是因为接触到了实际的生产项目，故而在这短短的一个月里也积攒了一些宝贵的经验和技巧。如果我脱离了生产项目的实际，没有做到实事求是，我是断不可能积攒这些经验技巧的。只能说，人的意识在实践（劳动）中产生 ，《实践论》说的是真理。我一直在呼吁大家，技术人员更要学习政治理论，政治理论不是因为你学的是理工科，就可以凭空在脑子里面冒出来的。政治理论是地基，技术是建立在政治理论之上的建筑。没有政治理论，技术再强也是虚无。

首先，马克思主义者认为人类的生产活动是最基本的实践活动，是决定其他一切活动的东西。人的认识，主要地依赖于物质的生产活动，逐渐地了解自然的现象、自然的性质、自然的规律性、人和自然的关系；而且经过生产活动，也在各种不同程度上逐渐地认识了人和人的一定的相互关系。一切这些知识，离开生产活动是不能得到的。在没有阶级的社会中，每个人以社会一员的资格，同其他社会成员协力，结成一定的生产关系，从事生产活动，以解决人类物质生活问题。在各种阶级的社会中，各阶级的社会成员，则又以各种不同的方式，结成一定的生产关系，从事生产活动，以解决人类物质生活问题。这是人的认识发展的基本来源。

人的社会实践，不限于生产活动一种形式，还有多种其他的形式，阶级斗争，政治生活，科学和艺术的活动，总之社会实际生活的一切领域都是社会的人所参加的。因此，人的认识，在物质生活以外，还从政治生活文化生活中（与物质生活密切联系），在各种不同程度上，知道人和人的各种关系。其中，尤以各种形式的阶级斗争，给予人的认识发展以深刻的影响。在阶级社会中，每一个人都在一定的阶级地位中生活，各种思想无不打上阶级的烙印。

马克思主义者认为人类社会的生产活动，是一步又一步地由低级向高级发展，因此，人们的认识，不论对于自然界方面，对于社会方面，也都是一步又一步地由低级向高级发展，即由浅入深，由片面到更多的方面。在很长的历史时期内，大家对于社会的历史只能限于片面的了解，这一方面是由于剥削阶级的偏见经常歪曲社会的历史，另方面，则由于生产规模的狭小，限制了人们的眼界。人们能够对于社会历史的发展作全面的历史的了解，把对于社会的认识变成了科学，这只是到了伴随巨大生产力------大工业而出现近代无产阶级的时候，这就是马克思主义的科学。

马克思主义者认为，只有人们的社会实践，才是人们对于外界认识的真理性的标准。实际的情形是这样的，只有在社会实践过程中（物质生产过程中，阶级斗争过程中，科学实验过程中），人们达到了思想中所预想的结果时，人们的认识才被证实了。人们要想得到工作的胜利即得到预想的结果，一定要使自己的思想合于客观外界的规律性，如果不合，就会在实践中失败。人们经过失败之后，也就从失败取得教训，改正自己的思想使之适合于外界的规律性，人们就能变失败为胜利，所谓"失败者成功之母"，"吃一堑长一智"，就是这个道理。辩证唯物论的认识论把实践提到第一的地位，认为人的认识一点也不能离开实践，排斥一切否认实践重要性、使认识离开实践的错误理论。列宁这样说过："实践高于（理论的）认识，因为它不但有普遍性的品格，而且还有直接现实性的品格。"马克思主义的哲学辩证唯物论有两个最显著的特点：一个是它的阶级性，公然申明辩证唯物论是为无产阶级服务的；再一个是它的实践性，强调理论对于实践的依赖关系，理论的基础是实践，又转过来为实践服务。判定认识或理论之是否真理，不是依主观上觉得如何而定，而是依客观上社会实践的结果如何而定。真理的标准只能是社会的实践。实践的观点是辩证唯物论的认识论之第一的和基本的观点。

我曾经看过一篇阿里云的技术团队写的一篇介绍Harness工程（约束工程）的文章，里面对于如何落实harness、harness项目的文档目录长什么样子等等讲得头头是道，可是我第二天上班一试才发现，这文章里面讲的东西华而不实，根本没法落实到实际的一个项目当中去。因此，我决定结合我们集团的实际项目，写两篇文章来分享我这一个月的经验和技巧。第一篇也就是本篇，《在AI时代，如何从0接手一个项目？》。第二篇则发生在第一篇之后，叫《在生产环境中和AI协作编程》。

对于自闭症谱系障碍、ADHD、抑郁症、焦虑症患者，文章最后同样也有应对方法。

---

为什么是从0"接手"一个项目，而不是从0"开发"一个项目？

AI推广普及之后，我们在网上见过最多的有关于AI编程的内容无非就两种，一种是"非专业背景如何氛围编程一个新项目"，另一种就是"我/别人氛围编程的项目产生了什么效果"。但其实还有第三种------锐评前两种。（不得不感叹一下互联网生态的多样性）总结一下第三种的话术，大概有以下几种：

• 某些只有前端页面的网页根本不配称之为"项目"；
• 就算你做出了完整的项目，你没办法盈利，你的商业模式不完整，甚至于没有。所以你的项目只能算个玩具。
• AI的上限取决于人的上限，AI只是抬高了下限，所以"文科生"做出来的东西只能符合第一条，因为现在的AI还没办法解决软件工程层面的问题，而项目的复杂度上来了，免不了要牵扯到软件工程，可是"文科生"又不会软件工程，因为"隔行如隔山"。

但其实在我看来，这种说法只说对了一半。因为他们漏了另一种情况------接手一个项目。

在实际的求职环境中，企业招程序员，很少是因为企业想从头开发一个系统，最普遍的情况往往都是"我们已经有了一个系统，我们招人是为了维护这个系统的"；而如果是给客户做软件开发解决方案的公司，那么这个理由也会变成"我们招人是因为人手不够，想提升开发效率的"。这种情况在招聘软件上有一个专门的二级或三级岗位选项，叫"运维开发工程师"。听名字你是不是以为是机房运维那种的？其实它就是程序员的其中一种，我也被这个名字骗过。运维开发，才是最普遍的岗位需求。我只见过一个想从头开发一个系统的公司，那家公司是我们大连本地的一家教辅材料出版社，因为最近两年AI编程出圈爆火，所以他们也想探索一下AI编程，让AI使用python语言开发一个教辅材料的电子版学习资料。由于这家公司没有IT行业的基因，外加他们对AI的态度是"谨慎探索"，所以他们想招一个会python的、来了就能干活的、同时稍微会使用AI的程序员。这家出版社离我家还挺近，走路10分钟就到了，但因为我不会python，也成了一件挺遗憾的事。

从后疫情时代开始，经济连年下滑。再加上AI爆火给了企业降本增效的借口，未来开发新项目的需求会越来越少，维护现有项目的需求会越来越多。

假如你不会编程，也不懂软件工程，该怎么接手一个项目？

我记得在学计算机网络的时候，老师在介绍计算机网络的时候讲了一句话：

服务器里的虚拟世界是现实世界的延申，现实世界是虚拟世界的基础。

不知为何，这句话我一直记到了现在。后来我读到了一篇介绍AI做企业编程的文章，作者同样说了一句话：

在用AI协作编程之前，一定要梳理公司的业务。如果不梳理公司的业务就让AI干活，那无非只是将纸质文档电子化而已，文档之间彼此没有任何联系，把这样的文档喂给AI，只会成为上下文的腐殖质。

网络世界是现实世界的延申，软件也同样是公司业务的延申。软件不是只是将纸质文件数字化、电子化这么简单，在学软件开发之前一定要意识到这一点。业务是需求，软件是供给，没有需求，供给就是空中楼阁。所以，在AI编程之前，第一件事就是要理清业务逻辑；在接手项目之前，同样要先弄清楚项目背后的业务逻辑。接手一个项目的过程，就是理清业务逻辑的过程。

当下，IT行业的就业寒冬似乎已经无人不知了。归根结底，企业的用工需求萎缩是一方面，还有一方面就是过于精细化的团队分工导致个体在AI面前根本没有竞争力。在此必须给没有专业软件开发的人科普一下一个专业的项目团队是如何分工合作开发出一款商业化软件的。

1. 立项：顾名思义，就是公司领导觉得"想开发这样一个产品"或者"有必要开发这样的产品"，然后领导就开始委派产品经理写《商业需求文档》来证明自己的想法是正确的、有商业价值的。接着让项目经理做PPT、写可行性分析报告，领导拿着项目经理做的PPT和报告向更大的领导在私下里或者会议上进行汇报，说服了大领导，于是这个产品的项目就成立了。

2. 项目经理：项目经理就相当于工地上的监工。这个角色要监督整个开发周期，工作流基本就是：立项 → 计划制定 → 任务分解 → 进度跟踪 → 风险控制 → 验收交付。由于工作流贯穿整个项目周期，所以后面还会再看见他。

3. 组建团队：项目成立之后，团队成员有两种方式：第一种是抽调其他项目组的成员，组成一个新的项目组，也就是"内部转岗"；另一种就是原地招聘，视项目的轻重缓急程度，选择急招或者长期招聘。在实际过程中，一般都是二者结合的，先抽调少量人员组成一个小团队，然后再招聘剩下的人。当然，现在经济下行，所以一般都是从各个项目中分别抽出少量的人来组成新团队。当然，如果是新项目事关整个集团的兴废存亡，那么几个项目组合并成一个大项目组也是有可能的，最经典的就是千问APP。去年11月，阿里巴巴秘密启动"千问"项目，打算基于Qwen大模型打造一款同名个人AI助手，全面对标ChatGPT。首先，阿里先将Qwen大模型团队从达摩院中剥离出来，并入通义实验室（因为千问APP就是通义实验室开发的），然后统一大模型的名字，接着再抽调高德地图、花猪、淘宝闪购、天猫等团队的成员到千问项目团队中，最终历时三个月，终于在年前上线了"外卖免单"活动。

4. 产品经理：产品经理就是设计产品，决定产品长啥样的人。项目经理写了可行性分析报告，得出结论是"可行"并立项之后，就该轮到产品经理去思考目标用户的需求是什么了。因为"科技要以人为本"，软件有什么功能，取决于目标用户有什么需求，用功能去满足需求，这就是需求分析。产品经理需要写三大文档，《商业需求文档（BRD）》分析商业价值，《市场需求文档（MRD）》分析市场价值，《产品需求文档（PRD）》分析产品功能。《产品需求文档》就是AI最有价值的上下文，因为它除了定义产品有什么功能之外，还定义了功能模块之间的关系和产品业务逻辑。《商业需求文档》主要给领导汇报，《市场需求文档》给销售人员和运营人员看，让她们明白这个产品有什么功能；《产品需求文档》才是给技术人员看的。

5. 软件架构师：软件架构师在拿到《产品需求文档》之后，就开始着手设计软件工程架构，编写《系统概要设计说明书》。包括软件有哪些模块（一个功能的更详细流程）、组件（一个功能的代码边界）、API接口、有哪些服务、采用什么技术栈......说白了就是将用户需求转化为技术需求。有的人会混淆软件架构师和系统架构师，你可以把系统架构师视作软件架构师的进阶版，系统架构师不仅要会设计软件架构，还要设计硬件、网络、操作系统、数据库等层面的技术架构。一般入行5年以上可以做软件架构师，入行8年左右才能做系统架构师。

6. 制定开发计划：项目经理在拿到《系统概要设计工程师》后，首先先分析这个产品有哪些功能，这个功能有哪些组件，组件下面又有多少细分的模块。接着再分析这个项目的工作量，通过工作量来计划先开发哪个功能、后开发哪个功能、一个功能开发多长时间，还要考虑开发成本、规划预算的问题。这个阶段同样有一大堆文档要写，《工作分解结构》《任务清单》《工作包》《任务依赖关系》《里程碑清单》《资源分配表》《项目计划书》《进度计划书》《资源计划》《沟通计划》《风险管理计划》《成本/预算计划》、用来追踪进度的时间轴或甘特图，等等。

7. 软件工程师：有的人说，"这不就是程序员吗，还说得这么高大上。"其实不是。在AI时代，这两者的差异反而变得越大。我在之前写的文章里提过，AI只能代替程序员，代替不了软件工程师。区别在于，软件工程师有主观能动性，而程序员不需要有。程序员就是一颗随时被替换的螺丝钉，说是耗材都不为过。软件工程师是程序员的直接领导，他需要和软件架构师一起商定产品采用的技术栈，同时将软件架构设计转换成功能代码，比如如何实现那些模块和组件，这也是需要设计的，只不过这是更细分的场景。最后再把功能拆分成一个个任务分配给底下的程序员。

8. 程序员：一个开发团队中最底层的角色，真正将设计实现成代码的执行者、工人。程序员不需要关心别人是怎么做的，只需要关注分配给自己的那一亩三分地怎么实现，也不需要关注怎么设计API------软件架构师早设计好了，只要你写的代码没问题，别人只要调用这个API就能正常运行。正因如此，程序员也无需操心整个项目、整个公司的业务逻辑是怎样的，因为这个问题太宏观了，这不在他的职责范围之内。但在AI时代，正是因为程序员不懂业务，才让这个职业群体变成了可怜的耗材，被辞退了还要被炼化成同事.skill，而放眼望去，整个行业也再无他们的立足之地。一般来说，入行两年之内都是初级程序员，2~4年是中级程序员，5年做软件工程师，8年做软件架构师，10年以上做系统架构师，可是在AI的冲击下，以后就再也没有初级程序员了。随着人才断代、生老病死，以后也不会再有软件工程师、软件架构师、系统架构师了。

9. 开发阶段：分配完任务，就开始正式进入开发流程了。在这个阶段，每个角色都会互相沟通、互相配合。项目经理会监督开发进度和项目风险，程序员遇到问题会找软件工程师，软件工程师也搞不定的，则会去请教软件架构师；产品经理也会中途修改需求、添加需求，这又少不了"兵戎相见"的戏码；这其中也少不了一次次地开会，产品经理要开会讨论需求，软件架构师要开会讨论技术选型，还要时不时地给程序员做培训。

10. 测试工程师：项目开发完毕后，程序员将代码提交，由软件工程师将每个程序员的代码合并成一个完整的项目，然后移交给测试工程师。在项目经理和软件架构师的监督下，测试工程师会全面地测试这个软件。测试方式共有13种：

    • 单元测试：测试工程师先编写外围代码，作为测试的模具，然后把单个函数或方法放进去，测试输出结果是否符合预期。完成后删除外围代码。

    • 集成测试：将单元组装成一个功能，比如"用户登录"功能，检查是否正常。

    • 系统测试：测试整个软件是否正常运行。

    • 验收测试：把软件交付给用户，让用户试一试。一般对应软件内测和公测。内测和公测在业内分别叫"Alpha测试"和"Beta测试"，于是俗称"AB版测试"。

    • 回归测试：用户检查出问题了，在返工修改之后，重新检查一遍有没有问题。

    • 性能测试

      • 负载测试：测试一下软件在极限状态下可以服务多少客户。
      • 压力测试：在超出设计指标的情况下，看看软件稳不稳定。
      • 并发测试：和负载测试角色互换，在访问人数固定的前提下看看会不会出问题。
      • 响应时间测试：测试从操作到响应中间的时间。

    • 安全测试：检查软件有没有网络安全漏洞等。

    • 兼容性测试：测试不同的操作系统、浏览器、硬件设备、软件版本等的兼容情况。

    • 冒烟测试：快速验证是否正常，决定是否进行更深入的测试。

    • 探索性测试：模拟用户视角，自由探索整个软件，看看会不会找到问题。

    • 自动化测试：使用工具或脚本进行自动化测试。

    • 黑盒测试：不考虑内部代码实现，只关注输入和输出结果是否正确。

    • 白盒测试：测试人员了解内部代码结构，测试代码路径和逻辑。

11. 运营：测试后发现没有问题。在经过团队评估后一致认为可以推向市场了，于是运营、销售、公关......都开始干活了。此时项目经理就完成了他的使命。在运营的过程中会不可避免地出现各种问题，于是就会重复上述步骤，就像验收测试和回归测试一样。

12. 生命周期结束：没有什么是长久的，软件也有它自己的寿命。一个软件结束生命周期的原因有很多，也许是运营团队不做人，也有可能是资金不够，还有可能是软件不再符合市场需求，总之它的生命周期结束了。有始有终，方为天道。

以上就是一个大致的软件生命周期的流程。需要注意的是，为了维持线性叙事，上述流程的每个环节都只能聚焦一个角色。实际上在真实的流程中，也会出现产品经理和软件工程师一起设计产品功能、软件工程师和软件架构师一起商议软件所用的技术栈、软件架构师和项目经理一起制定开发计划的时候。而且上述职业配置只是一种标准，实际开发中，因项目或公司的实际客观原因，会出现这个岗位职责让另一个人来承担、那个岗位职责压根就没有等情况。还是要具体问题具体分析。

由此可以看出，有一些自以为是的"文科生"，叫嚣着说"现在是技术门槛最低的时候，以后AI可以完全代替编程了，不要怕踩坑，大胆的干吧！"按照这些人的意思，似乎AI可以让上面12个步骤里的所有职位全部消失、所有人原地失业。也不好好想想，这可能吗？在想当然之前，能不能考虑一下最起码的底层规律？能不能做到实事求是？你的上限决定了AI的上限，如果你连测试有哪些种类都不知道，你又怎么可能驱使AI来帮你完成测试工作？

那么假如你是上面那个开发团队的新人，你该从何入手，接手一个新项目呢？

第一步：先看数据库

数据库才是真正承载业务的地方。一个系统真正承载什么业务，看它的数据库就知道了。数据库不光存储了大量的数据，可别忘了数据库的字段、表结构、表关系、数据库结构也同样蕴含着巨大的信息量。我个人觉得这些东西甚至比数据还要重要，因为数据泄露了顶多造成严重的安全事故，可是要是表结构、表关系、数据库结构要是泄露了，那相当于公司的整个商业模式都被泄露了，相当于直接给这家公司判了死刑。无数的竞争对手会像雨后春笋一样冒出来，疯狂挤兑生存空间。

因此，你可以将前端代码喂给AI，让AI帮你设计UI，你甚至可以将后端代码也喂给AI，让它帮你找出逻辑错误。可是万万不可将SQL语句上传 ，那才是一个项目真正的隐私。数据库承载了业务逻辑，而业务逻辑才是一个人、一个企业在AI时代真正的护城河。所谓"个人独特的不可替代性"，就是差异化竞争：在程序员中最懂业务、在业务人员中最懂软件工程、在所有人中最擅长使用AI。不要以为AI时代的软件工程不重要，恰恰相反，它的重要性仅次于业务逻辑。现在的AI受限于上下文长度，没法统筹整个项目。这时候就需要有一个懂软件工程的人，充当AI的灯塔。

现在主流的数据库可视化工具是Navicat，虽然收费，但强大。拿到一个数据库，先不要看表中都有什么数据，你连表之间的关系都没弄懂，看了也白看。而是应该先浏览一下这个数据库里都有哪些表、每个表有几行数据，然后点击页面右侧的第二个图标，那个是显示建表语句的。

数据库文件的本质就是SQL语句，数据库识别到SQL语句之后，再执行对应的操作。所以我们人类也要学会SQL语句，这样才能弄懂一个数据库里面的表关系。你可以不会任何编程语言，但为了数据安全，你必须会SQL语句。

这张表哪个是主键、哪个是外键，外键又跟哪个表有关系；那张表是存储什么数据的，为什么这里是非空，这个字段为什么要设计成递增/递减，如果我要查某个数据，应该哪些表联查，是左连接还是右连接......这就是数据库承载业务的根本原因。你可以在看不懂代码的时候自己慢慢啃，但是一旦你看不懂数据库，一定要赶紧问，要么问老员工，要么去问业务员 。业务员或许看不懂数据库，甚至或许连数据库是干嘛的都不知道，但是她绝对知道某个字段代表什么含义，或者某个字段为什么要设置成递增/递减。先放下你身为技术人员特有的傲慢，一定要不耻下问。

Navicat其实是一个系列，就像Adobe一样。在Navicat系列中，有一个软件叫Data Modeler，已经出到4了。这个软件是绘制数据库建模的。就像这样：

如果你不想下载多余的软件，Navicat for MySQL也自带这个功能。这个功能叫"模型"，在菜单栏中有一个专属的硕大图标，很容易找。

这个模型图就是你钻研数据库之后的产物。实际生产环境中的数据库十分复杂，几十张表都算少的；想查询什么数据，七八张表联查都是常态。有了这张图，团队之间协作也更方便。这也是学校教的理论和现实之间的巨大鸿沟。

第二步：罗列API接口

从这一步开始，视项目的保密程度，就可以适当地引入AI来协作了。如果项目的保密程度不高，那么从这一步开始，就可以让AI来帮你完成一些工作了。

一般来说，SpringBoot项目分为4层：
flowchart TD FE["前端请求\nHTTP GET/POST/PUT/DELETE"] subgraph Controller["Controller 控制层"] C1["@RestController\n路由注册"] C2["@RequestMapping\nURL → 方法映射"] C3["参数接收与校验\n@RequestBody @Valid\n@RequestParam @PathVariable"] C4["响应封装\nResult‹T› / ResponseEntity"] C1 --> C2 --> C3 --> C4 end subgraph Service["Service 业务层"] S1["@Service\n业务接口定义"] S2["@ServiceImpl\n核心业务逻辑"] S3["@Transactional\n声明式事务管理"] S4["AOP 切面\n日志 / 权限 / 限流"] S1 --> S2 --> S3 S4 -.-> S2 end subgraph Entity["Entity 数据模型层"] E1["Entity 实体类\n映射数据库表"] E2["DTO 数据传输对象\n接收前端参数"] E3["VO 视图对象\n封装响应数据"] E1 --- E2 --- E3 end subgraph Mapper["Mapper 数据访问层"] M1["@Mapper / @Repository\nMyBatis 接口定义"] M2["XML 映射文件\nSQL 语句编写"] M3["动态 SQL\n‹if› ‹choose› ‹foreach›"] M4["BaseMapper‹T›\n通用 CRUD 继承"] M1 --> M2 --> M3 M4 -.-> M1 end DB["MySQL 数据库"] FE ==> C1 C4 ==> S1 S3 ==> E1 S3 ==> M1 M2 ==> DB DB -.-> M2 M1 -.-> S3 E3 -.-> C4 S2 -.-> C4 style Controller fill:#e0edff,stroke:#3b82f6,stroke-width:2px,color:#1e3a5f style Service fill:#f0e6ff,stroke:#a855f7,stroke-width:2px,color:#3b1f5e style Entity fill:#d9f5eb,stroke:#10b981,stroke-width:2px,color:#14432c style Mapper fill:#fef3d6,stroke:#f59e0b,stroke-width:2px,color:#5c3d06 style FE fill:#f0f1f4,stroke:#64748b,stroke-width:1px,color:#2d3748 style DB fill:#fde8e8,stroke:#ef4444,stroke-width:2px,color:#5c1a1a style C1 fill:#e0edff,stroke:#3b82f6,color:#1e3a5f style C2 fill:#e0edff,stroke:#3b82f6,color:#1e3a5f style C3 fill:#e0edff,stroke:#3b82f6,color:#1e3a5f style C4 fill:#e0edff,stroke:#3b82f6,color:#1e3a5f style S1 fill:#f0e6ff,stroke:#a855f7,color:#3b1f5e style S2 fill:#f0e6ff,stroke:#a855f7,color:#3b1f5e style S3 fill:#f0e6ff,stroke:#a855f7,color:#3b1f5e style S4 fill:#f0e6ff,stroke:#a855f7,color:#3b1f5e style E1 fill:#d9f5eb,stroke:#10b981,color:#14432c style E2 fill:#d9f5eb,stroke:#10b981,color:#14432c style E3 fill:#d9f5eb,stroke:#10b981,color:#14432c style M1 fill:#fef3d6,stroke:#f59e0b,color:#5c3d06 style M2 fill:#fef3d6,stroke:#f59e0b,color:#5c3d06 style M3 fill:#fef3d6,stroke:#f59e0b,color:#5c3d06 style M4 fill:#fef3d6,stroke:#f59e0b,color:#5c3d06

MyBatis工作在mapper层，SQL语句就是MyBatis自动映射的，所以这部分不需要我们操心。

如果是从0开发一个软件，首要之事就是设计数据库字段，第二重要的就是设计API接口。接口就像电子产品的插口一样，它定义了不同模块、不同层级之间传递参数的交互规范。由于定义了统一的标准，所以它可以让各模块解耦，实现多态支持（至于什么是多态，这是面向对象编程的概念。面向过程、面向对象、继承、多态，都是软件工程的基础知识，应该自己掌握，而不是外包给AI），也就有了扩展性。而且统一的标准还对测试和团队协作特别友好。

在SpringBoot项目中，API接口在控制层（controller）。所以我们只要将controller.java文件作为上下文引用，再配上如下提示词，就可以得到一份《API接口设计文档》了。

这是一个SpringBoot项目的Controller层代码，你需要：
1. 用markdown的表格语法列出所有API接口的URL、HTTP方法和功能描述
2. 按业务模块分组
3. 推断每个接口对应的业务操作是什么

那么AI就会给你类似于这样的一份文档：

名字	传输方式	URL	用途
create	POST	/api/dispatch/create	创建调度单
list	GET	/api/vehicle/list	查询车辆列表
status	PUT	/api/driver/status	更新司机状态

这一步做完，你就知道系统提供了哪些业务能力。《API接口设计文档》不仅是用来团队协作、分配任务的依据，同时也是AI最有效的上下文。《API接口设计文档》应该和《项目目录结构》《软件概要设计说明书》《模块概要设计说明书》《数据库概要设计》等其他文档一起放进项目级规则里。当AI产生幻觉，或者不知道目标文件放在哪时，看一眼文档就能马上找到了，既节省上下文，又节省了词元。词元就意味着钱。

第三步：查看配置文件

配置文件告诉你系统连接了哪些外部系统、用了什么中间件、有哪些业务规则配置。在SpringBoot中，配置文件有两种，一种是SpringBoot应用配置，另一种是maven项目配置。应用配置一般在src/main/resources​或src/main/resources/config​目录下，文件名固定为application.properties​或application.yml​。使用Spring Initializr创建SpringBoot项目时，会自动生成这些配置文件。如果需要，开发者也可以手动创建application.yml文件，但这需要额外操作，不是默认行为。

maven配置文件的名字叫pom.xml，一般放在maven项目的根目录下：

my-project/
├── pom.xml           ← 就在这里
├── src/
│   ├── main/
│   │   ├── java/
│   │   └── resources/
│   └── test/
│       └── java/
└── target/

​pom.xml就不是自动生成了，而是由开发人员维护的。开发人员需要什么，就在这个文件里写什么。在编译阶段，编译器会根据这个文件，自动下载对应的依赖项。所以如果修改了这个文件，需要重新构建项目。

所以，你需要先找到xml、yml、json或者其他后缀名的文件，然后同样把它们作为上下文引用，然后发送如下提示词：

这些都是一个SpringBoot项目的配置文件。根据这些文件，从中提炼出这个项目都用了哪些技术栈、对应的版本，以及业务用途是什么。然后将这些内容提炼成一个文件名为`project-technology.md`的markdown文档，放在`.trae/rules`目录下。

提示词只要大概是这个意思就行，现在的AI在底层架构上都差不多，只要指令足够清晰、直白，基本上都能心领神会。然后AI会在项目级规则目录下生成一个markdown文件，然后去设置里刷新一下就可以生效了。当然，大概率是不用刷新的，只要放到正确的目录里，TRAE识别很快的。

上述提示词是针对后端的，其实前端也是同理，甚至更方便。除了使用本地的前端框架（如Vue、React）会产生配置文件之外，原生前端技术是没有配置文件的。所以只需要找一个上下文比较长的AI，让AI自己找到前端文件并总结技术栈，然后同样放到上述规则文件里就行了。

项目技术栈很重要。总结项目技术栈有两个作用：

• 帮助开发者固定版本。如果是Rust语言还好一点，大部分情况下，高版本可以兼容低版本。如果是Java，那么即使是跨了个小版本，可能引用的外部库的路径都不一样，从而导致版本兼容问题。而AI因为实时信息更新得比较慢，再加上AI只工作在项目目录里，不了解项目之外的情况，相当于孙悟空给唐僧画的一个圈，所以很难解决这种软件工程层面的问题。如果你自己不掌握软件工程专业的基础知识，不引导一下，可能AI这辈子都不会往版本号这个方面想。这也就是为什么我在前文认为"AI代替整个软件开发团队就是个笑话"。
• 作为AI的上下文。正因为上面的原因，所以AI需要知道这个项目用了什么技术栈，这样一来可以节省上下文，上下文越短，出现幻觉的概率就越低；二来不需要每次遇到问题的时候都现总结项目的技术栈了，将这个作为项目规则，每次和AI提问都会自动发送（在TRAE里可以自定义规则的生效时机，默认始终发送），相当于AI拿了一个目录去干活，肯定比两眼一抹黑要强得多。

第四步：还原核心业务逻辑

从这一步开始才需要读代码。既然是业务逻辑，所以读的肯定是服务层（service）的代码。当过程序员的都知道，写代码只占整个工作的不到20%，剩下的时间不是在解决API接口联调的问题，就是在去开会的路上，亦或是检查（review）别人的代码。检查别人的代码才是最痛苦的，尤其是对于我这种不会编程，但是会一点点软件工程、可以凭经验和感觉大致猜出来这段代码在干啥的人来说尤其如此，会编程的和不会编程的反倒都少一点这种痛苦。

对于会编程的人来说，这一步可以用AI，也可以不用。不用AI就是"古法编程"那一套------追变量名。这里的"变量名"是一个笼统的概念，泛指一切你可以自定义名字的"东西"。从这一个变量名到另一个函数/方法/类/结构体，然后再跳转到另一个文件......好处是你可以完全掌控整个项目的运行逻辑，缺点就是费时间。

而咱们这些不会编程的人，其实用AI也可以完成。虽然对项目的掌控程度肯定是在客观层面下降了，但是我们要把AI当成实习生，把自己当成中层领导，哪有领导自己下场微操的？那不成蒋校长了吗？ 所以，我们可以让AI来帮我们寻找隐藏在代码中的蛛丝马迹。视项目的重要程度，我们需要掌握的程度也不一样。如果只是一个人氛围编程出来的小项目，比如只有前端（HTML、CSS、JavaScript、Vue、React、TypeScript、next.js、Node.js），没有后端（C++、python、Rust、Java等），那么我们只需要知道主要的业务流程就行了。对应的提示词如下：

我想理解"调度单从创建到完成"的完整业务流程。以下是从Controller层开始的代码（在这里使用AI IDE的引用文件功能），请帮我：
1. 追踪这个流程经过了哪些类和方法
2. 每一步做了什么业务操作
3. 有哪些业务规则和判断逻辑
4. 用流程图描述整个过程

如果需要看其他类的代码，请告诉我需要哪些文件。

而如果是企业级、有很多功能的大项目，那么即使我们不会编程，也需要知道这个项目里都有哪些业务、对应的业务流程分别是什么。如果使用的是像TRAE、Qoder、CodeBuddy、Cursor这类AI IDE，那么就方便很多了。我一般会在设置好技能、安装好MCP、一切规则设置妥当、准备好最基础的项目文档之后，直接发送如下提示词：

根据`API接口文档.md`和`项目目录结构.md`，总结该项目的**全部**业务流程逻辑和功能模块设计，以及这些模块之间的流程，在`/Documents`目录下，将总结好的业务逻辑、功能模块设计、模块流程写进《软件需求规格说明书.md》《模块设计报告.md》《模块流程图.md》。《软件需求规格说明书》要囊括项目中**所有的**业务流程，《模块设计报告》里的**每一个**模块都要详细说明其用途是什么，承载了什么业务；《模块流程图》要使用mermaid语法进行绘制。最后，再根据这个项目已有的代码，在`/Documents`目录下总结出一个《软件概要设计说明书.md》，大纲参考行业内通用标准即可。

不需要告诉AI什么是《软件需求规格说明书》、《软件概要设计说明书》要包含哪些内容，AI知道。倒是人类需要了解一下什么是《软件需求规格说明书》。需求规格说明书是软件开发过程中最核心的文档之一，业务流程在其中占据重要位置。其内容主要包含以下内容：

内容模块	说明
引言	编写目的、项目背景、术语定义
系统概述	产生背景、主要功能、目标
业务流程	主业务流程的详细描述
功能清单	功能点的细分说明
功能详细说明	每个功能的前置条件、操作步骤、业务规则等

在某些大型项目中，业务流程也可能作为独立文档编写，作为需求文档的补充，帮助团队理解业务逻辑。通常配合业务流程图一起呈现。

至于《软件概要设计说明书》，说实话它并不是一个合格的AI上下文。因为它太杂了，什么都有，很容易让AI产生幻觉。不过对于人类来说，这反倒是个优点。所以相比于其他三个文档，这个文档才更应该是人类需要仔细阅读的文档。只要维护好这篇文档，它可以拆成好几个文档，相当于项目文档的目录索引。

至此，你就从0接手了一个项目，迈出了从接手到开发的第一步。但是我要提醒你，AI协助接手项目存在天花板。AI可以帮你理解业务流程和规则，但是没办法判断隐藏的 ​bug或者漏洞；AI可以帮你知道系统做了什么，却无法代替你敏锐地察觉出系统没做什么；AI也许可以发现明显的软件架构问题，但是没办法发现深层次的性能和安全隐患。让AI重构？AI也会左右脑互搏。这些，都需要你自己懂得软件工程和软件架构、会编程才能做到。AI的上限，永远都取决于你的上限。

自闭症谱系和ADHD人士该怎么办？

其实我自己就有自闭症特质和ADHD，但是因为精神科医生的排班太阴间了，导致号特别难抢，基本上只有每周三周五的半天时间，外加上医生也不全是专业的，所以我不仅没有得到什么医学支持，反而还受到了一些伤害。就我自己的感觉来说，哪怕我没有达到自闭症的诊断标准，那么我也肯定有ADHD。这不是什么互联网时尚单品，而是对我生活、工作、社交切实的影响。

社会对于"神经多样性群体"的支持也不够，这个群体常年徘徊在社会边缘，没有进入大众视野。有的人对这个群体充满恶意，而大多数人就算没有主观上的恶意，也因为对这部分群体不够了解而存在一些偏见和刻板印象，这也是一种间接的伤害。所以我觉得我有必要在我熟悉的领域提供一点帮助。同时我也希望从来没了解过神经多样性群体（ND）的神经典型性人士（NT）也可以在读完这一部分之后，对神经多样性群体了解更多一些。

研究发现，ASD（自闭症谱系障碍）和ADHD（注意力缺陷多动障碍）经常共病，约有30-80%的ASD儿童同时符合ADHD诊断标准，也就是所谓的"双A"。所以下面我会把两个群体合起来讲。

第一步：看数据库

这部分对于自闭症谱系来说优势明显。因为数据库是高度结构化的信息，看上去就和Excel表格差不多。主键、外键、数据类型、约束条件，全是明确的、无歧义的、不需要"读空气"的信息------全在SQL语句里写着呢。谱系人士天生擅长从规则系统中发现模式和异常。上文说的"看建表语句、分析表关系"，对谱系人士来说甚至可能比NT做得更好，因为NT容易靠直觉跳过细节，而谱系人士会逐字段地啃，然后在脑中构建完整模型。这就是自闭症谱系的障碍所在------面对复杂的生产级的关系型数据库时，这种"偏执"很容易让大脑过载。

解决办法也很简单。还记得我们为什么要看数据库吗？不就是为了那一张《数据库模型图》吗？这张图同时也是解药。看一点，梳理出一点成果，就立刻 画到图里去，不要试图用脑子记，高级工程师来了都记不住。

如果说看数据库对自闭症谱系的挑战就相当于CPU满载，那么对ADHD的挑战就相当于电脑内存容量不足。对于ADHD来说，这就是泥潭，甚至是整个流程里面最无聊的一步。七八张表的联查关系？ADHD的大脑在第三张表的时候就已经开始想"我是不是应该直接看代码了"。所以他们很容易跳过这一步，直接冲到后面去看代码或让AI生成文档。即使坐下来看了，注意力会在"这个字段命名不规范"和"为什么用INT不用BIGINT"这些非核心细节上跑偏。然后看到一半突然想到"我应该先把Navicat装上"，接着去装软件，装完又发现需要许可证（Navicat是商业软件，要钱的），然后去搜破解教程......两小时后数据库一个字没看。

不过我相信ADHD和自己的神经特质朝夕相处这么多年，想必已经有一些自己的经验和方法了。去医院拿到诊断后服药是一个方法、降低维持注意力的门槛是一种方式、给自己设置多巴胺奖励还是一种方式。总之，你可以用各种方式来告诉自己，"梳理数据库其实是很轻松的工作"。

社交障碍

同样是在看数据库这一步，上文有一句话：

先放下你身为技术人员特有的傲慢，一定要不耻下问。

这句话对于自闭症谱系和ADHD来说是共有的核心矛盾，但难度不同。遇到不懂的就应该要多问人，但现实中，自闭症谱系和ADHD人士在职场中"问人"的社交成本就是比神经典型性群体高。这不是缺点，是客观事实。

先说自闭症谱系。

根据《DSM-5》诊断标准，社交（语用）沟通障碍（SCD）被明确定义为一种独立的神经发育障碍，其核心特征是持续存在的社交沟通困难，包括在社交情境中使用言语和非言语交流的缺陷，如难以根据听众调整沟通方式、理解言外之意、维持对话等。然而，SCD的诊断有一个至关重要的排除标准：个体不能同时满足自闭症谱系障碍（ASD）的全部诊断标准 ，特别是必须缺乏受限的、重复的行为、兴趣或活动模式（RRBs）。这意味着，SCD适用于那些仅有社交沟通缺陷而无RRBs的个体，无论其年龄如何。

那次去看精神科医生，虽然没拿到自闭症谱系的诊断，但是医生却斩钉截铁地肯定我有社交障碍 （只是我对这个诊断不服就是了） 。只是由于不需要开药，所以并没有诊断书。

但是对于自闭症谱系来说，社交方面的障碍比社交沟通障碍更严重。自闭症谱系的难点不在于"不肯问"，而在于不知道该问什么、什么时候问、问了之后怎么处理对方的模糊回答。假如业务员说"这个字段就是记录一下状态嘛"，对于神经典型性人士来说会继续追问"什么状态、状态从哪来到哪去"，但自闭症谱系人士可能字面理解了"记录一下"就停止了追问。然后出了什么问题，就会让他们产生挫败感，渐渐地就不问了。

除此之外，自闭症谱系还会恐惧不确定性、厌恶变化，再微小的变化也不行。而社交对他们来说就是一种不确定性，因为对方不会按照他们设想的那样来交流，任何回复都有可能。本质其实是一种刻板行为。这就是我认为自己其实应该是自闭症谱系的原因，因为我也这样。我对此的应对方式就是：先问AI，再问人，问人之前打腹稿。

先把你准备问人的问题先问一遍AI，看AI怎么回答，然后基于AI的回答去追问人。这样你问人的时候已经有了一个"锚点"------

"我看到代码里是这样写的，AI说可能是XX意思，但我拿不准，您能确认一下吗？"

这比"这个字段什么意思"好回答得多，对方也更容易给出精确的回答。

而在决定问别人之前，或者是要说什么话之前，先思考自己要说什么，准备好一整套完整的话术，比如说：

这个字段叫XXX，我注意到它是NOT NULL的，而且和YYY表有外键关系，请问它记录的具体是什么业务含义？在什么场景下会被写入？

拿着准备好的话术去问别人，能够大幅度降低不确定感。如果是比高功能自闭症（阿斯伯格综合征）更严重一些的轻度自闭症和中度自闭症，还可以额外再预演一下所有可能出现的情况，并想好应对措施。

如果实在不想开口，写文档。 把你的理解写成文档，发给业务方或老员工："我整理了一份XX模块的业务流程，您有空的时候帮忙看一下有没有理解偏差。" 书面异步沟通对谱系和ADHD都更友好。

而对于ADHD来说，社交障碍则变成了"等不及问"。脑子已经跳到第三步了，第一步还没做完就想绕过去，而"不耻下问"需要停下来、组织语言、找到对的人、等待回应。这一串动作本身就是对执行功能的巨大消耗。然后由于ADHD的工作记忆非常短，经常转头就忘了自己要干嘛、曾经干了什么。对此，也许想到什么就赶紧记下来才是最有效的应对方式。

最后，无论是ASD还是ADHD，要记录每一次"问了之后发现和我想的不一样"的案例。 这些案例才是你真正的个人知识库，同时也是隐式业务流程的沉淀、AI的避坑记忆文档。《实践论》说得好------

人们经过失败之后，也就从失败取得教训，改正自己的思想使之适合于外界的规律性，人们就能变失败为胜利，所谓"失败者成功之母"，"吃一堑长一智"，就是这个道理。

对谱系人士来说，这些案例可以弥补"读空气"能力的不足；对ADHD来说，这些案例是比任何文档都有效的"记忆锚点"。

第二步：罗列API接口

由于这一步的AI自动化程度很高，所以这一步不会对两个群体造成什么太大的障碍。倒是需要提醒一句：要给AI的输出加一个强制检查环节 。 AI生成表格之后，不要直接用，而是打开Controller文件，用查找功能（Ctrl+F）逐个搜索@RequestMapping​、@GetMapping​、@PostMapping​，和AI的表格做交叉验证。因为API接口文档是非常重要的项目级 文件，一旦这个文件出了问题，以后所有与之有关的对话都会出问题，你的整个项目就废了。

第三步：查看配置文件

配置文件是个高度嵌套的树形结构，而且很长，大项目里动辄几百上千行。自闭症谱系容易再次陷入"逐行解读"的模式，而ADHD看到这个长度则会当场大脑宕机。但是可别忘了，我让你们打开配置文件的目的是让AI帮你提炼项目的技术栈，而不是让你亲自下场微操的 。让AI帮你提炼，然后你自己再大致扫一眼，做到心中有数即可。提炼技术栈的目的是为了让AI在写代码的时候不出版本兼容性问题。换句话说，这是给AI看的，不是给人看的。

第四步：还原核心业务逻辑

这是四步法中最难的一步，对两个群体来说都是。

对于自闭症谱系来说，数据库表结构是精确的、API接口也是精确的，但业务逻辑往往是"原则上是这样，但特殊情况要那样处理"；而且有些业务规则没有写在任何文档里，只存在于某个Service方法里的一个if​判断中。自闭症谱系人士可能逐行读了代码、理解了每一行的字面含义，但没意识到这个if本身就是一个业务规则。

这是两个障碍，但归根结底都是一个------模糊性。自闭症谱系人士对模糊性和不确定性非常不适 ，可能会反复追问"到底哪种情况算特殊情况"，而业务员的回答往往是"看情况"。"看情况"，这三个字对自闭症谱系人士来说就是一种折磨。这不是能力问题，而是思维方式的差异------自闭症谱系人士倾向于信任显式声明，而生产环境中的业务规则往往都是隐式的。

应对方法：

• 在让AI梳理业务流程时，加上一句提示词：

  ​ 特别注意代码中所有的条件判断（if/else/switch），每一个条件判断背后都可能隐藏着一条业务规则，请逐一标出并解释其业务含义。

  这一句话可以把隐式逻辑显式化，大幅降低遗漏概率。

• 准备一个"业务规则疑问清单"，采用"红绿灯标记法"：

  • 🟢 已理解并验证
  • 🟡 AI给出了解释，但需要找业务方确认
  • 🔴 完全不理解，必须找人问

• 找人问的时候，​不要问"这段代码什么意思"，而是问"在XX场景下，系统应该怎么处理" 。前者是把对方拉进你的技术世界（对方可能听不懂），后者是把问题放在对方的业务世界（对方如鱼得水）。这是社交策略，不是技术策略。

对于ADHD来说，障碍则集中在注意力方面。首先，这一步需要持续的高度专注 。 追踪一个业务流程从Controller到Service到Mapper再回来，中间可能跨越五六个文件，每个文件几百行。ADHD的注意力在这段旅程中大概率会断链------追到第三个文件的时候已经忘了第一个文件在干什么了。

其次，AI生成的文档太长，看不下去。 前文让AI生成《软件需求规格说明书》《模块设计报告》《模块流程图》三份文档。对于大项目来说，这些文档加起来可能上万字。ADHD看到这个篇幅，直接放弃阅读。

应对方法：

• 不要一次追踪完整流程。 把"调度单从创建到完成"拆成："创建调度单""分配车辆""司机确认""调度单完成"四个独立的小流程，每次只追踪一个。每个小流程让AI单独生成一段mermaid流程图，不要合在一起。四张小图 > 一张大图。
• 不要让AI一次性生成三份大文档。 让AI先只生成《模块流程图.md》，而且只生成核心模块的。看完流程图、脑子里有了画面感之后，再生成《模块设计报告.md》，而且每个模块单独生成、单独看 。至于《软件需求规格说明书》和《软件概要设计说明书》，这两个本质上是你"接手完毕之后"的沉淀文档，不是"接手过程中"的工具文档。先接手，后沉淀，不要反过来。
• 用mermaid流程图作为你的"外挂大脑"。 ADHD不擅长记逻辑，但擅长看图。一张流程图比一万字描述对ADHD有用得多。把流程图打印出来贴在显示器旁边，比放在电脑里的任何文档都有效------因为视觉恒定刺激 （一直能看到）比按需检索 （需要时去打开文件）对ADHD友好得多。

抑郁症和焦虑症怎么办？

我强烈不推荐抑郁症或焦虑症患者来接手任何一个项目。 其实对于精神病人来说，接手代码是一个非常燃烧生命力的工作，编程也是对体力和脑力的双重考验。你以为网上称计算机专业就是"赛博土木"是在开玩笑吗？最起码土木工程不会同时考验脑力和体力，在一段时间内只会挑一个来考验。他们本来就不是健康人，怎么能够胜任这种繁重的工作？生病了就应该好好休息，而不是一再挑战自己的身体极限。

但也不能排除一种情况，万一编程是有些病人脱离畸形的原生家庭、实现经济独立的唯一方式呢？所以我们也要科学地认识抑郁症和焦虑症。

抑郁症在编程领域的核心挑战有两种，意义感丧失 和精神运动性迟滞 。前者会让患者陷入虚无，自己做什么事情都没有任何意义，然后就开始自我攻击；而后者则会让思维变得迟缓、难以集中注意力。如果达到极端程度，还可能发展成紧张症 ，DSM-5-TR诊断系统将其标注为"伴紧张症特征的重度抑郁发作 "。其核心特征包括木僵（例如持续数小时静坐不动、姿势固定、对外界指令无反应或仅有微弱反应）、缄默、蜡样屈曲、违拗等。这不是道德素质或人品败坏，而是发生在生理层面的疾病。

对此，应对方式就是降低心理预期和执行门槛。比如正常人在工作时会先打开电脑，然后打开IDE软件，接着点击"文件"→"打开文件夹"，最后开始正式工作。而对于重度患者而言，连打开电脑都特别困难。首先是"好想动，但动不了"，紧接着就是"别人打开电脑这么容易，为什么我不行，我怎么这么废物，我怎么可以容忍自己这么废物"，然后就开始自我攻击了。所以要降低自己的心理预期。今天先开机就已经很了不起了。开机很简单吧？如果是笔记本电脑的话，先把盖子掀开，然后按一下开机键就行了。明天先开机，再双击桌面软件图标。第三天先开机，再打开软件，再打开项目所在文件夹。

读不懂代码也不要自我攻击。别忘了你的身份，你是一个病人。要允许自己生病，也要允许自己读不懂代码，这也是在认清客观现实。谁这一生能做到百病不侵？更何况你得抑郁症肯定有其原因。这篇文章大部分都是在让AI帮你读代码、整理文档，这很大程度上也会减轻你的心理负担。大不了在照着文章执行的过程中，顺便让AI用你能听懂的方式给你讲一遍就是了，无非是多耗一些词元的事。

有些人不理解抑郁症患者，总是在说什么"运动就好了呀，运动就能康复。你不去运动，说明你就是不想好"，那我问你，你让一个坐轮椅的骨折病人从轮椅上站起来，病人站不起来就是人家不想好呗？你这是赤裸裸的污名化！谁不知道有氧运动可以缓解抑郁症？你以为天下就你最懂抑郁症？这已经不是有没有同理心的问题，我因为自闭症特质，我也没有同理心（述情障碍），但我怎么就知道抑郁症病人的现实挑战呢？纯粹就是你脑子里对抑郁症没有科学的认识，把自己的刻板印象当成真理，自己无知还不知道自己无知！不知道自己无知的人，就是最标准的蠢货！

晒太阳可以补充维生素D，而维生素D除了可以补钙，还可以改善抑郁情绪；有氧运动可以提升多巴胺，多巴胺同样可以缓解抑郁。但倘若你让抑郁症病人直接去太阳底下跑步、去游泳馆游泳，那他大概率是做不到的。所以真正的改变往往都是从"去楼下花园的长椅上坐一会"开始的。这同样是在降低执行门槛和心理预期。这些都是通用的。

而焦虑症的核心挑战则是灾难化思维与对未知的恐惧、完美主义导致分析瘫痪。 焦虑来源于对失控的恐惧，而"对失控的恐惧"也分三种：对提交代码的截止日期的恐惧、对代码有缺陷的恐惧、对AI生成结果不完美的恐惧。应对方法请参照前文自闭症应对模糊性和不确定性的方法，核心思想就是容许未知，意识到"就算是发生未知情况，也不会产生灾难性后果"，从而打破灾难化思维的错误逻辑。

针对完美主义导致的分析瘫痪，焦虑症患者应该意识到，天底下没有任何程序是没有bug的，只要是人造的东西，都有缺点。项目文档也一样，项目文档应该是跟随代码变动而随时更新的东西，不存在静止的、永恒的项目文档。软件尚且有生命周期，人还有寿命，更何况是项目文档？局部的错误不会导致整体方向跑偏，AI会自动帮你修正错误的------现在就算是二等国产大模型都可以做到这一点了，要意识到真正的客观现实。

结语

写到这里，全文该收尾了。

回看这篇文章，从开篇引述《实践论》，到提出接手项目的四步法，再到为神经多样性群体寻找生存策略，贯穿始终的核心其实只有四个字：实事求是。

网上那些鼓吹"AI将立刻替代所有程序员"的自媒体，没有实事求是；那些脱离生产环境、靠"氛围编程"糊玩具还沾沾自喜的极客，没有实事求是；那些无视精神疾病患者的生理客观基础、站着说话不腰疼地喊出"你想开点就行了"的看客，更没有实事求是。

离开了物质的生产活动，人的认识就成了无源之水；脱离了客观的生理条件，谈主观能动性就是彻头彻尾的唯心主义。

在AI时代，技术门槛确实在降低，但"实事求是"的门槛反而变高了。因为AI太容易让你产生"我懂了"的幻觉，也太容易让你把思考外包给一段看似合理的文本。但请永远记住：业务逻辑才是真正的护城河，软件工程才是托底的基石，而你的上限，永远是AI的上限。 AI可以帮你梳理隐式的if判断，可以帮你画出Mermaid流程图，可以帮你生成《软件概要设计说明书》，但它无法代替你察觉系统"没做什么"，更无法代替你去承担生产环境崩盘的客观责任。

如果你是一个健康的开发者，请放下技术人员的傲慢，去贴近业务，去敬畏那些屎山代码背后的现实逻辑；

如果你是自闭症谱系或ADHD人士，请接纳你思维方式的差异，用AI做你的显式转换器和外挂大脑，用结构化对抗模糊，用视觉化对抗断链；

如果你正深陷抑郁或焦虑的泥沼，请首先承认并允许自己生病。这不是道德瑕疵，这是生理现实。不要用健康人的标准来PUA自己，不要去想"我为什么不能像别人一样高效"。从掀开笔记本盖子开始，从双击IDE图标开始，从让AI替你读一段代码开始。哪怕今天只是让电脑屏幕亮起来，这也是你在这个赛博土木的工地上，完成的一次伟大的实践。

技术再怎么狂飙突进，写代码的、改Bug的、接手烂摊子的，终究还是肉身凡胎。AI是一台强大的挖掘机，但坐在驾驶室里的，依然是你。

认识规律，尊重现实，降低门槛，开始行动。这就是我们在AI时代生存的唯一解。

下一篇，该讲一讲如何跟AI协作编程了。