DeepSeek 写代码的正确姿势

把 DeepSeek 当成一个很懂代码、但需要你把需求下清楚的搭档，合作就顺了：它不缺知识，缺的是你给的信息和事后的验证。同一句「帮我写个脚本」，有人拿到能直接跑的代码，有人拿到一堆要重写的半成品，差别全在提问和验收这两头。

需求说清三件事：输入、输出、约束

「帮我写段代码」这种问法，模型只能连猜带编。说清三件事效果立刻不同：输入是什么（文件格式、字段、数据样例），输出要什么（格式、字段、排序规则），有什么约束（语言版本、能不能引第三方库、性能要求）。对比一下：「用 Python 读取 data.json，按 score 字段降序输出成 CSV，score 缺失的行跳过并记录到日志」，这句话给出去，回来的基本就是能跑的东西。约束里容易漏的是「不要做什么」：不要引入新依赖、不要改动函数签名、不要输出解释文字。反面清单写得越全，返工越少。

给数据样例是最容易被忽略的一步。贴两三行脱敏后的真实输入，比描述半天格式都直观——字段名、嵌套结构、缺失值长什么样，模型看一眼就清楚，不用靠文字描述去还原。反过来，输出也建议给个样例，一行目标 CSV 的样子，胜过一句「输出成表格」。

复杂功能先要思路，再要代码

一上来就要完整代码，方向错了就全错。先问「实现这个功能有哪些思路？各有什么优缺点？」，看完思路确认方向，再让它写。这一步能拦住两类浪费：方案本身不适合你的场景，或者模型选了一条你维护不了的路线。确认思路时顺手把语言版本、依赖限制这些前提说死，后面就不反复返工。

逻辑复杂、分支多的功能，先确认深度思考开着再问，按任务类型判断要不要开，深度思考的开关时机里有具体办法；开头没有现成的好问法时，官方提示词库的改编三步可以直接搬来用。

报错要整段贴回去

出了 bug 只说「报错了，帮我修」，模型只能凭空猜。有用的贴法是三件套：完整的报错信息（traceback 一行不删）、相关代码段、你期望的行为。报错里的行号和异常类型就是线索，删掉等于把线索捂住了。修完还有一招：让它顺手解释这次错的根因，一句话就行。知道根因，同类错误下次自己就能避开；不知道，你就成了人肉报错转发器。

让它自己挑毛病

代码能跑不代表代码能用。AI 生成的版本经常漏掉异常处理：文件不存在、网络超时、空列表、编码问题。写完主动问一句「这段代码有哪些边界情况和潜在问题？」，它会补上你没意识到的漏洞。再让它列一份自测清单：验证过哪些输入情况、哪些没验证，没验证的你自己补测。看不懂的代码让它「逐行解释」，既避免盲用，也是学得快的办法。

多轮修改的会话容易越滚越乱，隔一段就把当前版本贴进新对话重来，上下文干净，输出更稳；旧会话的整理和导出，历史记录管理里有一套现成办法。

三条不能让步的底线

AI 生成的代码必须人工审查，涉及支付、登录、隐私数据的部分尤其要逐行看——模型的代码看起来专业，不代表逻辑正确，更不代表安全。密钥、密码、内网地址不要写进发给它的代码里，脱敏之后再贴。以及，别让它帮你写任何违规的程序，这条没有商量余地。

写代码提问速查

• 需求三件套：输入、输出、约束，附数据样例
• 复杂功能先要思路清单，确认方向再要代码
• 报错整段贴：traceback + 代码 + 期望行为
• 写完追问：边界情况和潜在问题有哪些
• 代码必须人工审查，密钥永不进提示词

还有一个值得养成的习惯：让它写完代码后附一份「改动说明」，列出做了什么、基于哪些假设。下次你自己改这段代码，或者换个人接手，这份说明比注释还管用。描述越具体、验证越及时，这个搭档就越好用。