老项目难在没人告诉你它为什么长成这样。新项目正好反过来，最难的不是写代码，是从空白走到能打开、能跑通第一件事。这两个阶段用代码助手的方式完全不同，我踩过的坑大多集中在后者。
开头别一上来要一整个系统。我第一次就这么干，让助手给我写一个带登录、上传和消息推送的小站，结果来回改了几个小时，哪个环节都没落地。后来改成只做一件事：先让页面能在浏览器里打开，哪怕是个空壳。 通义灵码 和 Trae 在这种「先跑起来」的阶段最顺，描述一句就能出能跑的骨架，你改改端口就能开。
骨架出来之后才是填肉。这时候我的做法是先把目录定死，前端放哪、后端放哪、数据库连哪，我自己写，不让助手发挥。助手在新项目里最容易犯的毛病是自由发挥，目录一层套三层，你找不着文件。定死结构再让它往里填，出来的东西好改很多。
第二个字段名要统一。新项目最怕的就是同一个意思一会儿叫 name 一会儿叫 title，我吃过一次，查一下午才明白是助手几次生成时命名不一致。现在我在开头就把字段表写死在注释里，让它照着生成。
装依赖这步别交给它自动跑。让助手给你命令，你自己复制执行，看到报错自己读一遍。我图省事让它直接改配置，结果它改错了版本，跑起来一片红。遇到报错先贴原文给它，别自己转述，转述容易漏掉关键那行。
报错处理有个笨办法很好用：把报错原文整段粘回去，前面加上你刚才改了什么。它比你自己更记得上下文。我一般三轮之内能解决，超过三轮就说明设计有问题，先退回去改方案，不要硬调。
写测试这一步新项目一定要做。哪怕只测一个接口，跑通了你知道它真的能用。 CodeBuddy 和 Cursor 都能顺着你已有的代码写出风格一致的测试，比你自己从零写快。测试不是完工后的额外活，是判断它有没有真跑对的标准。
跑通第一件事之后，就该考虑形态了。需要每天开着改的，用 Cursor 这种 IDE 形态最顺手；要靠命令跑批处理的， Claude Code 那种命令行形态更省事；国内团队一起改的， 通义灵码 和 CodeBuddy 的协作链路更齐。选形态按你接下来的活儿定，别按别人推荐定。
我一般还留一手：把跑通的那一版存成最小可用版本，之后每次大改前先回到这儿。新项目最容易失控的就是越改越远，半夜发现跑不起来了都不记得改了什么。
安全这块新项目要提前想。密钥别写进前端，别提交到仓库，本地用环境变量。助手写示例时常常图省事直接给个写死的配置，你照抄就把口子开了。
提交也要勤。每解决一个能描述清楚的小问题就提一次，写一行说明。新项目没提交记录的毛病我犯过，重来一次才想起来差在哪。
环境这块新项目要一次配好。Node 版本、Python 版本、数据库版本，定下来写进 README，别让助手每次按自己的判断装。我吃过亏，它给我装成了另一个大版本，跑得好好的突然报错，查两小时才发现是版本换了。定死版本再让它往上写业务，省心很多。
耗时的往往不是写代码，是等它改。一条指令发过去要等它回，中间别连着丢下一条，容易撞车。我习惯等它回完再发，一轮只问一件事，反而比一口气扔五个需求快。新手最容易在等待里反复改同一句提示，越改越乱，最后哪句都不是你本来想说的。
还有个细节，新项目的 README 要它写。别觉得这是形式，等一周后你自己都忘，写清楚怎么装、怎么跑、第一步看哪个页面，比任何文档都管用。
你打算从零写的是个什么项目？页面类、数据类还是要接硬件的，告诉我规模，我按这个给你一份从空白到能跑的第一趟顺序，哪几步该慢、哪几步可以快。