让代码自己长出骨架
论文讲的是：大模型从零写完整项目时，如何通过动态调整架构蓝图大幅提升生成质量
1问题
想象你让一个编程助手从零搭建一个小型书店系统，只给了一句白话需求：要有登录、商品展示、购物车和结算功能。现在的通用大模型拿到指令后，通常会把所有逻辑塞进同一个巨型脚本里，函数之间互相乱指代。当你后来想加个打折规则，登录流程直接跟着崩溃。症结在于，现有的代码生成工具默认你会提前发一份现成的文件夹模板过来；如果你真的要求白手起家，它们就会失去方向，写出的代码很快变成一盘解不开的乱麻。前人试图用硬编码模板或者让模型自由发挥来破局，但前者套不进千奇百怪的新项目，后者则注定撞上新项目特有逻辑的墙，最终产出一堆跑不通的碎片。要是这个助手能在干活的同时，自己一边画图纸一边调比例，让每张纸上的零件始终各归其位，局面会不会彻底翻盘？
2翻译
顺着刚才书店系统的例子，我们看这套新办法是怎么一步步落地的。你可以把它想象成一位手持双面绘图板的总建筑师。板子的左面钉着你的原始需求钉子，比如登录、结算；右面贴着正在生长的程序砖块，比如用户服务层、支付接口。两层砖块之间用连线把需求对应该负责的组件。助手开始动笔时，并不急着堆砌代码，而是先拿一把叫作模块化指标的软尺去量——这软尺的核心逻辑只有两条：自己人得挨得近，外行人得离得远。当购物车逻辑不小心扯动了登录校验，软尺读数下降，建筑师就执行一次结构切割动作，把纠缠的部分单独划出新文件夹，重新连线，再次上尺量。切割和测量反复轮转，直到左右两边的连线稳定下来不再抖动。图纸定型后，助手才切换模式，对着固定好的路线图逐块写代码，每写一块就附赠一张检查清单，清单全过才盖下一块。真正的差距藏在数字里：和当前最强的规划类对手相比，这套方法把功能覆盖度硬拉高了二十个百分点，测试通过率净增近三十个百分点。更反直觉的是，哪怕故意掐断图纸打磨的步骤，只让它快速定稿，结果依然稳稳压过基线，这和业界普遍相信的“想得越细做得越好”完全相反。
3核心概念
故事里真正扛事的家伙有三样。第一样是那双联动地图。它不是死板的表格，而是两张相互牵引的进度网。左网挂需求词，右网挂代码模块，中间的指针随时同步两者的匹配度。回到书店场景，一开始登录需求可能只对应一个孤立文件，随着任务展开，这张网会自动把零散零件吸成独立的功能岛，防止张冠李戴。第二样是按软尺刻度切分边界的设计选择。作者拒绝凭直觉安排文件夹，而是立下规矩：高内聚代表内部任务必须打包，低耦合代表外部调用尽量切断。当结算和库存模块咬死在一起时，系统识别出违反规矩的裂缝，直接挥刀分开，绝不妥协。这属于典型的结构设计取舍，宁可牺牲初期开发速度，也要换回后期改动的空间。第三样是图纸定型判定器。切得太碎会失控，所以系统设了个静止开关。只要连续两轮重新排列节点后，连线的指向完全没变，就强制锁死架构。锁定瞬间，编码线程正式启动，不再边写边拆。
4洞见
架构不该是开局敲死的天花板，而是边走边校准的指南针；好代码不是写出来的，是跟着结构约束自然长出来的。
5博导审稿
选题眼光很毒，直接把镜头对准了大模型最虚的环节——面对空白目录时的失焦状态。但有个底层预设我得提醒你盯紧：那套模块化指标目前主要靠代码文本相似度或函数调用频次来估算真实耦合，如果模型刚开始吐出来的全是占位符或者语法错误，软尺就量不准，整个演进循环很可能困在无效修剪里打转。实验诚意过关，横向对比干净，消融实验也老实交代了各模块贡献。文字功底偏工程说明书味，把演进过程写得像操作手册，缺几个失败迭代的现场切片对照。综上给 weak accept。底子扎实，工程闭环完整，但理论护栏留了一道缝，后续得把指标失效时的兜底策略补齐。
6启发
这意味着你可以把这套边走边画图的逻辑直接嫁接到你自己的系统里。迁移层面：你现在的智能体如果在做数据处理流水线，可以给它塞一套同样的双轨映射表，让任务节点随数据量波动自动扩缩，省去手动配调度树的麻烦。混搭层面：把你现有的自动化测试框架和这里的定型开关串起来，一旦测试报错率跳升就自动触发图纸微调，能把返工周期直接砍半。反转层面：别再把架构评审当作编码前必须走完的过场了，试着把评审拆解成生成后的实时反馈回路，先动手搭架子再对齐，往往比空想蓝图快得多。三条路你挑一条都能立刻试水。