各行各业怎么用

程序员与开发者

写代码、读代码、排错、写文档、生成测试。

写代码的人用 AI，是这一行最占便宜的一件事，但也是最容易翻车的一件事。占便宜在于：重复的样板代码、看别人的烂代码、猜报错原因，这些活儿 AI 真的能帮你省下大量时间。翻车在于：它写的代码永远"看起来很对"，跑起来才发现边界情况全没处理；更要命的是，很多人习惯顺手把公司代码直接粘进去，那等于把家底往外搬。

这一页不讲玄的，只讲每天都在发生的事：需求怎么拆、函数怎么写、别人的代码怎么读、报错怎么查、测试怎么补、文档怎么出，以及最要紧的那条线——什么能贴、什么绝对不能贴。

两条红线，先划清楚

红线一：公司代码、密钥、数据库连接串、客户数据，不能粘贴到公开的 AI 工具里。包括但不限于：未开源的生产代码、API Key 和访问令牌、数据库密码和连接字符串、用户手机号邮箱身份证号、支付流水、内部接口地址、服务器 IP 和端口、未发布的产品设计文档。这些一旦贴出去，可能是违反公司制度、违反保密协议，严重的还涉及法律责任。要处理这类内容，只能用公司内部合规部署的工具，或者先把敏感部分全部替换成假数据再问。

红线二：AI 生成的代码，必须自己审查、自己测试之后才能上线。尤其是涉及安全（登录、鉴权、加密、防注入）、支付（订单、退款、金额计算）、权限（谁能看什么、谁能改什么）、数据删除和迁移这几类逻辑——AI 写出来的东西必须逐行看懂、逐行验证，看不懂就不用。AI 不会为线上事故负责，签字上线的是你。

一句话总结：AI 适合帮你写"能被测试验证的代码"，不适合替你决定"该不该这么写"。凡是你没法验证对错的地方，就是风险点。

这一页能帮你解决什么

拿到一句模糊的需求（"加个导出功能"），把它拆成一份能直接排期的任务清单。
写那些你不熟的样板代码：读配置文件、调接口、遍历目录、拼 SQL、处理时间格式。
接手陌生项目时，让 AI 先把某个文件或某个函数讲一遍，你能快速看懂它在干什么。
面对满屏红色报错，快速缩小范围，知道该先看哪一行、该加什么日志。
给自己的代码做一次"审查员视角"的检查，找出空值、越界、异常没处理这些问题。
生成单元测试和边界用例，尤其是你懒得想的极端输入：空字符串、超大数字、负数、重复提交。
把一坨没有注释的老代码，补出能看的注释和函数说明。
写接口文档、README、部署说明，不用对着模板一个个填空。
写规范的提交信息（commit message）和变更说明，团队协作少挨几句骂。
学新框架时，先拿到一条"先学什么、后学什么"的路线，不用在教程里迷路。
把一段绕口的报错或技术文档，翻译成你能给产品经理解释清楚的话。

先看一个真实例子

先看看新手最常干的事：把报错一贴，问"这啥意思"。

你我的代码报错了怎么办？

AI程序报错可能有很多原因，比如语法错误、逻辑错误、环境配置问题等。建议您检查一下代码是否有拼写错误，确保依赖安装正确，再看看是不是版本不兼容。如果还不行，可以把完整的报错信息发送给我，我帮您看看。

这段回答不能说它错，但它一个有用的字都没有。因为你什么信息都没给它——没有代码、没有报错、没有环境、没有期望结果，它只能把"可能的原因清单"念一遍给你听。这一来一回，时间就浪费掉了。

换成下面这种说法，效果完全不一样。注意三件事：最小可复现代码、完整报错、期望结果和已经试过的办法。

你Python，处理订单金额时踩了个精度问题，想请你判断根因。

代码如下（最小复现）：

prices = [0.1, 0.2, 0.3]
total = 0
for p in prices:
total += p
print(total == 0.6)

输出：False，打印 total 得到 0.6000000000000001

期望：total == 0.6 为 True。场景是订单金额累加，最后要跟用户实际付款金额比对。

已试过：改成先乘 100 再除 100，还是 False；也试过用 round(total, 2)，不放心，怕在大额订单上出问题。

AI根因：这不是 Python 的 bug，是二进制浮点数本身的特性。0.1、0.2、0.3 在二进制里都是无限循环小数，存进内存时就已经做了截断，累加三次之后误差被放大，得到 0.6000000000000001。所以用 == 比较必然失败。这类问题在所有使用二进制浮点数的语言里都存在，不只是 Python。

三个改法，按推荐程度排：

1）涉及金额就用整数"分"来存和算（最推荐）
prices_cents = [10, 20, 30]
total_cents = sum(prices_cents) # 60
print(total_cents == 60) # True
这样完全没有精度问题，换语言、换数据库都不会变。只在展示给用户时除以 100。

2）用 decimal 模块，并显式指定精度和舍入方式
from decimal import Decimal, ROUND_HALF_UP
total = Decimal("0.1") + Decimal("0.2") + Decimal("0.3")
要点：一定要用字符串构造 Decimal，别写 Decimal(0.1)，那等于把已经带误差的浮点数转进来，白做。舍入方式要显式写出来，不要依赖默认值，否则不同场景下结果可能不一致。

3）只是做比较的话，别用 ==，改用容差判断
abs(total - 0.6) < 1e-9
但这只能解决"判断相等"，解决不了"存进去就已经不准"，所以金额场景不建议用它兜底。

还要注意两点：
· 数据库那一侧也要对齐。如果列类型是浮点型，存进去还是会有问题，金额字段应该用定点类型或者整数分。
· 前后端交互时，金额不要用浮点数传，用字符串或整数分，否则序列化成 JSON 的时候可能又引入一次误差。

请务必自查以上代码我没有在你的环境里跑过，请用真实数据在本地验证一遍；金额相关逻辑上线前，建议补上专门的金额计算测试用例。

看出来了吗？第二种问法的关键在于：你把"复现条件"给全了。它不需要猜，你也不需要来回问三轮。而且它最后主动提醒你"自己验证"——这也是你该有的习惯：任何 AI 给的代码，都当成一份"待审查的同事提交"来看待。

可直接复制的提示词

需求拆解成任务清单

我是【前端／后端／全栈／数据】工程师，技术栈是【例如：Python + FastAPI + PostgreSQL】。
现在要做一个需求：【两三句话描述，例如：给后台加一个订单导出功能，支持按日期筛选，导出 Excel，数据量大概几十万行】

请帮我拆成一份可以排期的任务清单，要求：
1. 按"数据层 → 接口层 → 前端 → 测试 → 上线"的顺序分组；
2. 每条任务写成一句话，明确"改哪一层、做成什么样"，不要写"优化代码"这种空话；
3. 标出哪几条必须先确认清楚才能动手（例如产品没说清导出上限是多少）；
4. 标出哪几条有性能或安全风险，需要特别注意；
5. 最后告诉我这个需求应该先后端还是先前端，以及为什么。

不要写代码，只要清单和判断。

写一个函数（含边界要求）

请用【语言和版本，例如：Python 3.11】写一个函数，功能是：
【一句话说清输入和输出，例如：输入订单列表和一个日期区间，返回该区间内订单总金额，按币种分组】

约束条件：
- 输入数据格式：【贴一小段假数据的结构，不要贴真实数据】
- 边界情况必须处理：空列表、日期区间前后颠倒、金额为负数、缺币种字段、时间带时区；
- 不要引入第三方库，只用标准库；
- 函数要有文档字符串，说明参数、返回值和可能抛出的异常。

输出要求：
1. 先给完整代码；
2. 再单独列出"这段代码在哪些情况下可能出错或被误用"；
3. 再给 5 条针对这个函数的测试用例（只写用例描述和输入输出，不用写完整测试代码）。

读懂别人的代码

下面这段代码是别人写的，我要接手维护，但看不懂整体逻辑。

语言：【例如：Java】
代码：
【粘贴代码。注意：把公司名、接口地址、密钥、真实业务字段名替换成假名】

请帮我：
1. 用一段话概括"这段代码到底在干什么"，用大白话，不要堆术语；
2. 逐段说明每块的作用，标出哪几行是关键逻辑；
3. 列出它依赖的外部东西（数据库、接口、全局变量、环境配置）；
4. 指出 3 个读代码时最容易搞错的地方；
5. 如果我要修改【说明想改什么行为】，应该从哪一行下手。

解释报错（缩小排查范围）

【语言／框架版本】：【例如 Node.js 20 + React 18】
我遇到一个报错，请帮我判断根因，不要泛泛列可能原因。

完整报错（原文粘贴，不要删行）：
【粘贴报错全文，包括调用栈；敏感路径和域名替换成 xxx】

最小可复现代码：
【贴能复现这段报错的最少代码，去掉业务逻辑】

期望结果：【本来希望它怎么跑】
已试过的办法：【例如：升级过依赖、清过缓存、换过数据库连接方式，都没用】

请回答：
1. 最可能的 1 个根因，以及依据是报错里的哪几行；
2. 如果不是这个原因，第二可能是哪个，怎么快速区分这两种情况；
3. 给一个具体的下一步动作（改哪一行、加什么日志、跑什么命令）；
4. 明确列出"还需要什么信息才能确定"，不要猜。

代码审查与重构建议

请扮演一个严格但不啰嗦的代码审查者，审查下面这段代码：
【粘贴代码，敏感信息全部替换】

我的关注点：【例如：可读性、异常处理、性能、并发安全】

请按严重程度从高到低输出，每条格式为：
- 问题（一句话说清错在哪）
- 位置（哪个函数或哪一行）
- 为什么是问题（会产生什么后果，用具体场景说）
- 建议怎么改

要求：
1. 不要只夸不批，也不要为了凑数硬挑毛病，没问题就说没问题；
2. 单独列出"我可能被坑的边界情况"，至少 3 条；
3. 如果这段代码涉及安全、金额或权限，请单独标红提醒我哪些地方必须人工复核；
4. 只给建议，不要直接重写整个文件。

生成单元测试与边界用例

下面是我的一个函数，请帮我生成单元测试：
【粘贴函数代码，业务字段名可以替换成假名】

测试框架：【例如 pytest／JUnit／Jest】
我的关注点：不要只测"正常路径"，我更想要能暴露 bug 的用例。

请输出：
1. 正常场景用例（至少 2 条）；
2. 边界用例，至少 6 条，覆盖：空输入、只有一个元素、极大值、极小值或负数、重复值、类型不对的输入；
3. 异常用例：说明哪些输入应该抛异常，抛什么异常；
4. 每条用例前面加一句话说明"这条在防什么 bug"。

另外请单独告诉我：这个函数里有哪些分支是现有用例覆盖不到的。

写注释与接口文档

请帮我给下面这段代码补注释，并生成接口文档。

代码：【粘贴代码，敏感信息替换】
项目里的注释语言：【中文／英文】
文档格式：【例如 Markdown 表格／OpenAPI 片段／JSDoc】

要求：
1. 函数注释写清：做什么、参数含义和类型、返回值、可能抛的异常、有没有副作用；
2. 只在"看代码猜不出意图"的地方写行内注释，不要每行都写；
3. 接口文档输出成表格：接口名 | 方法 | 路径 | 入参 | 出参 | 可能的错误码 | 备注；
4. 凡是代码里看不出来、需要我去确认的地方（比如这个字段为什么允许为空），单独列一份"待确认清单"给我，不要自己编。

写提交信息与变更说明

请帮我写 git 提交信息（commit message）。

我这次改动做的事：【用两三句话描述，例如：把订单导出改成流式写入，避免几十万行时内存爆掉；顺带修了一个日期筛选少了 8 小时的 bug】

团队规范：【例如：Conventional Commits，标题不超过 50 字符，正文用中文】

请输出：
1. 一条标准格式的提交信息（标题 + 正文，正文说明"为什么改"而不只是"改了什么"）；
2. 一段给同事看的变更说明，3-5 条，说清哪些行为变了、对使用者有什么影响、有没有需要配合改的地方；
3. 提醒我这次改动有哪些地方值得在代码评审时重点说明。

学新框架的路线

我是【例如：有 3 年 Vue 经验的前端】，现在要学【例如：Next.js 的服务端渲染和数据获取】。
目标是在【例如：两周内】能独立写一个带登录和列表页的小项目。

请给我一条学习路线，要求：
1. 按"第 1-2 天、第 3-5 天、第 6-10 天、之后"分阶段，每阶段写明：学什么概念、动手做什么小练习、怎么判断自己学会了；
2. 明确告诉我哪些概念是必须先懂的，哪些可以以后再补；
3. 列出 3 个新手最容易卡住的地方，以及卡住时该怎么查；
4. 不要推荐具体课程和付费产品，只说学习内容的顺序和判断标准。

新手容易踩的坑

坑一：把公司代码直接粘进去。错在哪：很多人觉得"就贴一个函数，能有什么事"。但真实情况是，一个函数里往往带着内部接口地址、业务规则、数据库字段，拼起来就能还原出你们的产品逻辑。这既可能违反公司的信息安全制度，也可能触碰你和公司签的保密约定。怎么改：粘贴前先动手改造——公司名和模块名换成 A、B，接口地址换成 example.com，密钥和 Token 全部删掉，业务字段名换成 order_id 这样的通用名。改造完再问，效果一样好。涉及敏感数据的活儿，只用公司内部合规的工具。

坑二：AI 给的代码没跑过就提交。错在哪：AI 的代码常常"语法完美、逻辑有洞"。它会顺手用上你没引入的库、假设输入永远不为空、忽略异常、把并发场景当成单线程。这些在简单测试里根本看不出来，上线了才炸。怎么改：拿到代码先做三件事——本地跑一遍、跑一遍边界输入（空值、超大值、重复调用）、对照你的业务规则逐行读一遍。凡是涉及金额、权限、安全的地方，一定要自己重写核心判断逻辑，或者把 AI 的写法拿给同事看一眼再定。

坑三：报错只贴一行，让它猜。错在哪：只给"TypeError: cannot read property of undefined"这种一行信息，AI 只能列出十种可能，你一条条试反而更慢。怎么改：按这个顺序给全信息——语言和框架版本、完整报错和调用栈、最小可复现代码、期望结果、已经试过的办法。这五项给齐，它一次就能给出可执行的下一步；给不齐，就老老实实先自己把复现条件缩到最小。

坑四：把它当搜索引擎，问"这个 API 怎么用"。错在哪：AI 对具体版本的库和接口记忆经常过时，它可能给你一个上个版本才有的写法，或者编一个看起来很像的参数名。怎么改：用法类的疑问，优先查官方文档；把 AI 用在"帮我比较这几种写法的取舍""帮我把官方文档这段总结成步骤"这类地方。真要问 API，就把官方文档的相关片段一起贴给它，让它基于这段来回答，而不是靠记忆。

坑五：让它一次性重写整个文件。错在哪：改动范围越大，你越没法验证，而且很容易在无意中删掉别人写的兼容逻辑。怎么改：把任务切小——一次只改一个函数、一个分支、一处配置。让它输出"改动前后的对比"而不是整份文件，你 diff 一眼就能看出它动了什么。这样出问题也容易回退。

坑六：忘了它的知识有截止时间，也不了解你们的内网环境。错在哪：它不知道你们公司内部的框架、私有包、部署流程，也不知道昨天刚发布的新版本，但它不会主动说"我不知道"，而是会顺着你的话往下编。怎么改：涉及内部系统的问题，先把上下文喂给它（内部框架的用法示例、目录结构说明），并明确要求"如果信息不足，请直接说不确定，不要猜"。养成一个习惯：它对事实的断言，凡是你没法立刻验证的，都当"待核实"。

进阶一小步

1. 建一个私有的"提示词库"，按任务类型存好。把这一页的提示词改造成你自己的版本，用文档或代码片段工具存起来，按"拆需求、写函数、查报错、审代码、补测试、写文档"分好类。再往前一步，把这些提示词做成编辑器或命令行里的快捷片段，敲几个字母就能展开。团队里还可以共享一份，新人入职直接照着用，能省掉很多重复的口头解释。

2. 让它先"提问"再"回答"。处理复杂任务时，在提示词最后加一句："在给出方案之前，请先列出你需要我补充的 5 个信息，等我回答完再动手。"这一招的好处很明显：它会拿到完整上下文，输出的方案准确得多；而且你在回答它问题的过程中，经常自己就把需求想清楚了。这个方法在排查线上问题、设计新模块时特别管用。

3. 把测试用例反过来当"验收标准"用。接到需求时，先让 AI 帮你列一份测试用例清单（包括边界和异常），你和产品确认这份清单没问题之后，再开始写代码。这样有几个好处：需求里的模糊点在写代码之前就暴露了；写完之后你有明确的验收标准，不用靠"感觉应该没问题"来判断；将来回归测试也不用重新想用例。这个用法比单纯"让它写代码"价值大得多。

公司没配内部 AI 工具，我还能用吗？

先查公司有没有相关规定，很多公司是"可以用于脱敏后的通用问题，禁止粘贴代码和数据"。如果确实没有明确规定，稳妥做法是：只问通用技术问题（比如某种算法的思路、某个概念的区别、报错的通用排查方法），不粘贴任何一行公司代码、不描述任何真实业务数据。拿不准的时候，直接问你的主管或者信息安全负责人，别自己判断"应该没事"。这条线踩错的代价，远大于它帮你省下的时间。

AI 写的代码有版权问题吗？

这是个需要谨慎对待的问题，法规和各家平台条款都在变化，AI 也不能替代专业法律意见。实务上比较稳妥的做法是：把 AI 生成的代码当成"参考实现"，不要原样照搬到核心业务里；关键模块建议自己重写一遍并理解每一行；公司如果有开源合规或知识产权的审核流程，就走那个流程。涉及正式的法律判断，请咨询公司的法务或专业律师，以他们的意见和官方发布的规定为准。

它写的测试看起来都对，为什么还会有 bug？

因为它很容易写出"和实现同款假设"的测试——实现里漏了某个边界，测试里也一起漏了，看起来覆盖率很高，实际什么都没测到。破解办法有两个：一是让它专门针对"可能出错的地方"写用例，而不是针对功能描述写；二是把测试用例和实现分开两轮做，先写测试清单，你人工审一遍"这些用例真的能测出问题吗"，再让它写代码。另外，测试通过不等于逻辑正确，业务规则层面的验证还得靠你自己。

能不能让它帮我做架构设计？

可以，但要把它当"提方案的"而不是"拍板的"。让它列出三种可选方案，每种写清适用场景、代价、后期维护成本，你再结合团队情况、上线时间、招人难度自己决定。它不知道你们团队的技术储备、历史包袱和预算，这些恰恰是架构决策里最重的因素。建议在提示词里把这些背景交代清楚，并要求它"如果不确定，请说明还需要哪些信息"，而不是直接给你一个看起来完美的方案。

最后再强调一遍：公司代码、密钥、数据库连接串、客户数据，不要粘贴到公开的 AI 工具里；AI 生成的代码必须自己审查、自己测试之后再上线，尤其是涉及安全、支付、权限的逻辑。这一页讲的都是提效办法，红线只有这两条，守住了，它能帮你省下大量时间；越过去了，省下的时间可能要用事故来还。