用互联网黑话提需求，AI 真能听懂吗？

用互联网黑话提需求，AI 真能听懂吗？

前言

现在很多 AI 编程助手都强调“自然语言写代码”。这句话听起来很简单，但真正放到工作里，会遇到一个很现实的问题：如果需求本身说得很抽象，甚至全是互联网黑话，AI 还能不能听懂？

这篇文章根据视频内容整理，围绕一个问题展开：用“抓手、对齐、闭环、赋能”这类表达给 AI 提需求，它到底是在真正理解，还是只是在根据上下文猜测？

视频中使用的工具是 AWS CodeWhisperer。需要说明的是，CodeWhisperer 的相关能力后续已经并入 Amazon Q Developer。为了和视频画面保持一致，本文仍按视频中的名称 CodeWhisperer 进行讲解。

一、问题从哪里来：程序员真正怕的不是代码

视频开头先抛出了一个很典型的工作场景：公司里来了一个很会说话的产品经理。这里的“会说话”并不是指表达清楚，而是指需求听起来很高级，但落到开发实现时反而很难判断具体要做什么。

很多程序员并不怕写代码，真正消耗时间的是理解需求。需求里如果只有方向、口号和抽象词，开发就需要反复追问：输入是什么？输出是什么？边界条件是什么？失败场景怎么处理？

视频用“职业压制”来表现这种状态。这个表达虽然是调侃，但对应的工作问题是真实存在的：需求越抽象，开发成本越高；沟通越模糊，返工概率越大。

面对这种需求，程序员常见的心理活动不是“我不会写”，而是“我到底要写什么”。这也是 AI 编程助手出现后，很多人关心它能不能帮忙理解需求的原因。

所以这期视频的主题并不是单纯测试一个工具能不能补全代码，而是测试它能不能在需求表达不够标准的情况下，尽量还原真实开发意图。

二、能不能把一部分需求理解交给 AI？

视频接着提出一个问题：如果产品需求很抽象，能不能把一部分理解和实现工作交给 AI？

这个问题可以拆成两层。第一层是代码生成，也就是 AI 能不能根据注释、函数名和上下文写出代码。第二层是需求理解，也就是 AI 能不能从不够规范的自然语言中推断出真正要实现的逻辑。

如果只是生成简单函数，AI 编程助手通常表现不错。但如果需求变成“以某个指标为抓手，完成数据对齐，形成业务闭环”，难点就不在语法，而在语义。

因此，后面的测试重点就是：AI 能不能从这些不直接的表达里，抽取出明确的编程任务。

三、引出工具：AWS CodeWhisperer

视频中使用的工具是 AWS CodeWhisperer。它是 AWS 推出的 AI 编程助手，视频里把它作为“让 AI 帮程序员处理需求”的工具来演示。

它的定位并不是替开发者完整完成一个项目，而是在 IDE 中根据当前文件、函数、注释和上下文，给出代码补全或代码建议。

对于程序员来说，这类工具的价值主要体现在几个方面：减少样板代码、补全常见函数、根据注释生成实现、帮助快速搭出代码草稿。

四、在 VSCode 中安装 AWS Toolkit

视频进入实操后，先在 VSCode 扩展市场中搜索 AWS 插件。这里要安装的是 AWS Toolkit，它会把 AWS 相关开发能力集成到 VSCode 中。

安装完成后，VSCode 左侧会出现 AWS 相关入口。后续使用 CodeWhisperer，就需要通过这个插件完成登录和授权。

这里需要注意，视频演示的是当时的 CodeWhisperer 接入路径。如果现在重新安装，界面名称可能会以 Amazon Q Developer 为主，但整体逻辑仍然是：安装 AWS 相关扩展，登录账号，授权 IDE 使用代码建议能力。

五、登录 AWS Builder ID 并授权

启用 CodeWhisperer 前，需要登录或注册 AWS Builder ID。对于第一次使用的用户，流程通常会跳转到浏览器完成。

插件会提示打开外部网页。这里的逻辑是：VSCode 本地插件需要通过浏览器完成身份认证，然后再把授权结果返回到 IDE。

进入 AWS 授权页面后，需要确认允许插件访问对应能力。完成授权后，VSCode 才能正常接收代码建议。

如果还没有 AWS Builder ID，需要按页面提示创建账号。这个过程完成后，再回到 VSCode 继续测试。

六、第一次测试：让 AI 生成简单函数

完成登录后，视频回到 VSCode，开始写一个简单函数示例。这一步是为了先验证工具是否正常工作。

从画面可以看出，作者先写出函数相关内容，让 CodeWhisperer 根据上下文判断要补全什么代码。

这类场景是 AI 编程助手最常见的使用方式：开发者给出函数名、注释或已有代码片段，AI 根据上下文继续生成。

当插件开始工作时，画面中可以看到正在生成提示。这个过程类似于自动补全，只是它补全的不是一个单词，而是一段代码逻辑。

如果开发者认可生成结果，就可以选择接受提示代码段。这里仍然需要人来判断是否采用，而不是把所有建议都直接合并。

对于这种明确、局部、边界较清楚的代码任务，AI 编程助手一般比较容易处理。它能快速给出初稿，但是否符合当前项目规范，还需要开发者继续确认。

七、效率提升明显，但不能简单理解成替代程序员

视频中用“原本 5 天，结果 2 天”来表达效率提升。这个说法适合理解为：AI 能减少重复编码和查资料时间，让开发者更快拿到一个初版结果。

但它不能替代需求确认、架构设计、异常处理、测试验证和安全审查。AI 生成的是草稿，最终质量仍然要由开发者负责。

所以，AI 编程助手更适合做“提速工具”，而不是“最终负责人”。它能帮你写得更快，但不能替你判断业务方向是否正确。

八、开始加难度：用更抽象的需求测试 AI

视频后半段开始加难度。画面中提到 SQL 生成速度，说明测试已经从简单函数转向更接近日常开发场景的代码逻辑。

这里的难点不是某个语法点，而是 AI 需要判断：用户到底想比较什么？输入数据是什么？输出结果是什么？使用哪种语言或框架实现？

视频用夸张方式把 Left Join、PrestoSQL、SparkSQL 等术语放到一起，模拟真实开发里经常出现的“术语堆叠”。开发者看到这类需求时，往往需要先把抽象词和技术词翻译成明确工程任务。

如果需求只是“做一个数据能力的闭环”，开发者和 AI 都很难判断到底要写 SQL、写 Python，还是改接口。只有把输入、输出和处理规则说清楚，生成结果才会稳定。

九、AI 生成代码后，质量仍然要检查

视频中也提到代码审查和错误处理。这个点很关键：AI 生成代码后，不能直接默认正确。

开发者至少需要检查几个方面：业务逻辑是否符合需求，边界条件是否覆盖，异常处理是否完整，性能是否能接受，是否存在安全风险。

画面里用“QA 抓不出一个 bug”制造喜剧效果，但实际工作中不能把这句话当成结论。测试测不出 bug，不等于代码没有问题。

AI 编程助手更适合提高初稿速度，不适合替代测试流程。尤其是涉及数据处理、权限、资金、接口调用、生产环境操作时，更不能只看代码能不能跑。

这类工具确实会让开发者感到压力，因为它能完成一部分过去需要手写的工作。但从工程角度看，它更像辅助开发者，而不是替代开发者。

十、正式测试：互联网黑话需求能不能被理解

最后进入视频主题：用互联网黑话给 AI 提需求。

这类表达的问题在于，它经常不直接描述输入、输出和逻辑，而是用“抓手、对齐、闭环、赋能、组合拳”这样的词来包装意图。对于人来说，这些词可能需要结合上下文理解；对于 AI 来说，同样需要依赖上下文推断。

如果需求里出现“以数字为抓手”这类表达，把它翻译成工程语言，可能是围绕某个数字字段进行计算、匹配、排序、聚合或校验。

如果需求里同时给出数据样例和预期结果，AI 更容易理解；如果只给一个抽象口号，AI 只能猜。

视频里的效果是，AI 能够根据上下文生成接近需求的结果。这里可以说明一个结论：AI 对“黑话”的理解，并不是因为它真正接受了黑话，而是因为它能从上下文中还原出比较可能的任务。

从结果画面看，AI 最终能生成一段可用的代码逻辑。这个结果说明，在上下文足够明确的情况下，AI 可以容忍一部分不规范表达。

但这并不代表以后就可以故意把需求写得更抽象。对 AI 来说，越清楚的输入，越容易得到可靠的输出。

十一、结论：AI 能听懂一部分黑话，但清晰需求更重要

视频结尾用产品经理和程序员的关系做收束。真正让程序员痛苦的，不一定是技术难，而是需求不清。

AI 编程助手可以缓解一部分问题，比如生成代码草稿、补全函数、解释逻辑、辅助测试。但它不能替代清晰需求。

如果把需求写成“围绕核心抓手做链路闭环”，AI 可能能猜到一部分意思；但如果改成“输入两个数组，返回它们的交集，并保持原始顺序”，AI 的输出会稳定得多。

十二、给 AI 提代码需求，建议这样写

这期视频最有价值的地方，不是证明 AI 能听懂黑话，而是提醒我们：和 AI 协作时，需求写得越清楚，产出越稳定。

如果要让 AI 写代码，建议至少交代下面几件事：

互联网黑话可以作为调侃，但不适合作为正式开发需求。对 AI 也是一样。它可以根据上下文猜，但猜出来的结果不一定稳定。

十三、把黑话翻译成工程语言

在实际工作中，可以把常见黑话转换成更直接的工程表达。

AI 不怕自然语言，但怕缺少信息。把抽象词翻译成输入、输出、规则和样例，生成质量会明显更好。

十四、最终总结

这期视频表面上是在测试 CodeWhisperer 能不能理解互联网黑话，本质上是在讨论 AI 编程助手和需求表达之间的关系。

AI 可以帮助程序员生成代码、补全逻辑、降低重复劳动，也可以在上下文明确时理解一部分抽象表达。但它仍然需要清晰的目标、明确的输入输出和可验证的边界条件。

所以，真正高效的用法不是把需求写得更玄，而是把需求写得更具体。AI 负责生成草稿，人负责判断方向、控制质量和处理最终结果。

点击回到顶部