让 DeepSeek 写初步代码，我的三条规矩

起因

二月之后我用 DeepSeek 处理文字类任务的频率很高，于是很自然地想试试让它写代码。

我不是不会写脚本，是有些脚本写起来很烦：读一个目录、按规则改名、生成清单、导出表格。逻辑简单但细节多，写一遍要半小时，写完下次还用得上，属于”值得写但懒得写”的那一类。

于是我把它当成了一个能替我敲这些代码的人。

任务	我给了什么	结果	我改了多少
批量重命名文件	命名规则 + 示例	一次跑通	改了一个边界判断
解析日志提取耗时	十行样例日志	三次才跑通	重写了正则
Excel 多表合并	表结构说明	一次跑通	加了一列排序
写一个简单的 HTTP 接口	接口说明	跑通但结构乱	基本重写

总体印象：简单、独立、输入输出明确的脚本，它写得挺好；一旦涉及项目结构、依赖、状态管理，就得自己来。

第一，它不知道项目的上下文。 我让它”写一个读取配置的模块”，它给了个独立的函数；但我的项目里已经有配置读取的封装了。它不知道那些东西的存在，因为我没告诉它——而把整个项目讲清楚的成本，比我自己写还高。

第二，边界情况它考虑得少。 文件不存在、编码不是 UTF-8、某一行格式不对——这些它经常不处理，因为它给的样例里没有。跑起来报错之后我再回头补。

第三，命名和风格随意。 变量叫 data、temp、result，一个文件里出现三次 data。功能没问题，但三天后我自己看不懂。

第四，它会为了跑通而绕路。 有一次它的正则匹配不上，它没有去修正则，而是加了一层字符串替换先把内容改成能匹配的样子。测试通过了，逻辑却更脆了。

具体说说上面第二类问题。

我让它写一个读日志统计接口耗时的脚本。日志长这样：每行一个时间戳，中间有若干个字段，最后一列是毫秒数。

它第一版给了我一个正则，跑起来报错：某几行的字段数量不一样。它改了一版，加了容错；再跑，又有一行的毫秒数带单位。第三版它干脆改了逻辑：先把整行按空格切开，取倒数第二个字段，不管格式。

这版跑通了。但问题在于——它绕开了”格式不一致”这个真正的信息。

日志里那几行异常的记录，恰好是有问题的请求。我后来才发现，那批请求的超时时间是别人的三倍。如果当时直接用它的版本出结论，这个发现就被吞掉了。

从那以后我加了一条：它跑通之后，我要问一句”它是怎么处理异常行的”。这个问题的答案，往往比脚本本身更有价值。

用到现在，我的规矩收敛成三条。

一、任务粒度控制在”我能一眼验完”的范围内。

判断标准：它给回来的代码，我能不能在三分钟内判断对不对。能，交给它；不能，我先自己把任务拆小。

二、它必须先说思路，再写代码。

我会先要一段三五行的说明：打算怎么做、用哪些库、有哪些假设。看完再让它动手。这一步能拦掉大部分方向错误——不然等它写了八十行，方向错了就得全废。

三、涉及数据、文件写入、网络请求的代码，我自己写。

这三类出错代价最大：删错文件、写坏数据、把密钥发出去。让模型写这些，我省下的是十分钟，赌上的是不可恢复的后果。

两个月下来，上面那张表里的前三个任务我一直在用。它们有一个共同点：一次性的、输入输出明确的、跑坏了重跑一遍就行的小工具。

这些东西以前我拖着不写，现在随手就写了。省下的时间不算多，但那种”反正很快”的心态变化挺值钱——很多小自动化以前死在”懒得写”上。

用到现在，我觉得缺的不是”它写得更好”，而是它看不见整个项目。

它只能看到我贴给它的那几百行。我贴多了它记不住，贴少了它不知道上下文。这个限制决定了它只能写小东西。

2025 年年中我试过几种绕过办法——把项目结构写成说明、把关键文件一起贴进去——效果一般，成本不低。后来听说有工具能自己读项目、自己跑命令，但那时候还没用上。