做产品 PMaker
你负责的:判断 做什么,不做什么 给谁用,他卡在哪一步 信息怎么分组,页面怎么排 哪种做法在这个场景下不合适 做成什么样算合格 它负责的:实现 把描述变成能跑的代码 补全你没提到的常规部分 照着参考做出接近的效果 重构、改名、批量修改 解释一段陌生代码在干什么 它会把左边缺的那部分,用「最常见的做法」自动补上

分界不在难度,在这件事有没有唯一正确答案。有标准答案的它做得比你快,没有的它只能猜。

它会做的和不会做的

它能补全实现,补不上判断。你不做的那些判断,它会替你做,而且做得像模像样。

你会遇到的现象
  • 生成的东西能跑,但不是你想要的那个
  • 你说做一个列表,它顺手加了排序、筛选、分页、导出
  • 改到第三轮,它忘了第一轮的约定,你得重新解释一遍

分界在哪

这类事情交给谁原因
把描述变成代码有大量样本,做法收敛
重构、改名、批量替换机械且有明确的对错
解释一段陌生代码阅读比创作容易
照着参考做出接近的效果有对照物就有目标
决定做什么、不做什么取决于你的处境,它不知道
判断某个方案在这个场景合不合适需要具体的用户和约束条件
取舍:功能多还是快这是价值判断,没有标准答案
验收:做成这样算不算合格标准由你定,它只能照着量
划线的标准不是难易,是这件事有没有唯一正确答案。写一个复杂算法它比你快,决定要不要做这个功能它做不了。

它怎么补空

它不会说「你没说清楚」,它会用训练数据里最常见的做法把空填上。这个行为本身很有用——省掉了大量样板——但也是所有意外的来源。

你说的
做一个订单列表
它补的
· 分页,每页 10 条
· 按时间倒序
· 顶部加了搜索和筛选
· 右上角加了导出按钮
· 没有空态、加载态、错误态
补上的那几条是常见做法,未必是你要的;没补的那三条恰恰是真实环境里最常出现的。这个偏差是系统性的,不是偶然。

另外两个必须知道的特性:它每次只看得到你给它的东西,跨会话不会自动记住昨天的决定;它会一本正经地编,编出不存在的接口、参数、库。凡是要准的地方都得校验。

于是分工变成

把这四条连起来,就是这一类里其余几篇要讲的事:怎么写规格、怎么管上下文、怎么把约束沉淀下来。