拓冰网站定制 
最近 AI 辅助编程几乎成了绕不开的话题。身边不少同学问我现在 AI 都能自动生成代码了我还要不要花几个月去学某个框架万一学完就贬值了怎么办这个问题背后其实是同一个困惑——AI 时代到底什么能力才真正值钱。恰好最近看到关于 Notion 产品负责人的一期讨论核心观点一直在我脑子里转AI 把“会做”的门槛降下来了但把“知道该做什么、做到什么程度算好、怎么验证做对了”的门槛抬高了。换句话说比“技能”更值钱的是定义问题的能力、做出判断的能力以及管理上下文的能力。这篇文章不打算只聊观点。我会把这个判断翻译成一套可以在工程里落地的能力模型再通过一个完整的实战项目“提问力训练器”演示这些能力如何具体发挥作用最后整理 AI 辅助开发过程中的高频问题、排查思路和工程建议。无论你是产品、开发、测试还是数据方向的同学只要日常会接触 AI 工具这篇文章应该都能带来一些可落地的参考。1. 技能贬值时代什么在增值1.1 Notion 产品负责人观点的核心解读先补充一点背景。Notion 本身是一个重度 AI 化的知识管理与协作产品它的 AI 能力覆盖了文档总结、内容生成、智能问答、知识检索等常见场景。它的产品负责人谈“AI 时代什么更值钱”并不是在理论层面讲抽象概念而是基于大量真实用户的使用习惯和数据反馈得出的判断。这个判断浓缩成一句话就是AI 正在把执行层面的“技能”变成人人都能低成本获得的基础能力但随之而来的是对问题定义、结果判断和上下文组织这三类元能力的需求大幅提升。把这句话翻译成工程师日常听得懂的话以前我们比拼的是熟练度谁更熟悉某个框架、谁更快写出某段逻辑、谁记住了更多 API 的用法谁在团队里就更“值钱”。现在 AI 可以在几秒钟内完成代码生成、接口调用、SQL 编写、文档整理熟练度的差距正在被快速抹平。但 AI 并不知道你为什么要做这个功能不知道你的业务约束是什么不知道你的用户是谁也不知道验收标准是什么。如果结果不对它更不知道应该往哪个方向修正。这些判断和决策仍然只能由人来完成。所以比技能更值钱的是你对问题的定义能力、对过程的判断能力、对上下文的组织能力。技能本身没有消失但它从“核心竞争力”降级成了“基础成本”。1.2 为什么技能在 AI 时代容易贬值这里需要先做一个区分我们讨论的“技能”是指执行层面的熟练操作比如“会用某个 ORM 框架”“记得住某个 IDE 的全部快捷键”“会写某种 SQL 方言”“能快速搭建一个 Spring Boot 工程”。这类技能有两个共同特点第一可以被标准化描述第二可以被重复执行。可标准化、可重复恰恰是 AI 最容易替代的两类特征。大模型通过海量代码和文档的训练已经把绝大多数标准写法的生成能力内化到了模型参数里。当“技能”可以以极低成本被获取时它就不再是稀缺资源自然也不再是个人溢价的核心来源。但反过来看真正稀缺的是那些无法被一句话标准化的能力理解一个模糊业务需求背后的真实目标在多个可行方案中结合约束条件做取舍判断 AI 生成的代码是否真的满足当前场景在模型输出明显不合理时知道往哪个方向纠偏。这些能力没有办法通过“背 API”获得它们需要在真实的业务判断、工程决策和复盘反思中慢慢积累。所以说技能贬值不是坏消息。它其实是在提醒我们把时间从“记忆和重复”中释放出来花到“定义和判断”上去。1.3 比技能更值钱的三类能力结合 Notion 产品负责人的观点再补上工程实践中的体感我把“更值钱的能力”归纳为三类。第一类提问力也叫问题定义能力。它指的是你能把一个模糊想法拆成背景、目标、约束、参考示例和可验证的验收标准。同样面对一个需求有的人只能对 AI 说“帮我写个登录功能”有的人能说清楚“这是一个内部管理系统的账号登录要求支持邮箱密码登录、验证码过期时间为 5 分钟、失败 5 次锁定账号、登录日志写入数据库参考现有 xx 项目的风格”。后者得到的代码质量通常比前者高一个数量级。第二类判断力也叫结果评估能力。AI 生成的内容不总是对的甚至会一本正经地给出不存在的 API。判断力就是你能快速识别输出是否符合需求、哪里存在逻辑漏洞、哪里可能是幻觉、哪些部分需要人工再验证。它建立在领域知识和对业务目标的理解之上。第三类上下文管理力也叫信息组织能力。大模型的上下文窗口是有限的它不会记住你上一句话之后的所有细节。你能不能在有限的上下文里把最关键的信息传递给 AI决定了 AI 输出的质量上限。把项目背景、历史决策、领域知识整理成 AI 能理解的上下文本身就是一种工程能力。这三类能力不是空中楼阁。接下来的章节我会把它们逐一还原成工程师的具体动作并用一个实战项目演示。你可以发现它们完全可以通过刻意练习来提升不需要等待什么重大机会从下一个需求描述、下一段提示词、下一次 AI 辅助编码开始就可以着手训练。2. 把观点翻译成可执行的能力模型2.1 从“命令执行者”到“需求定义者”过去很长一段时间开发者的日常是“接到需求 - 拆任务 - 写代码 - 提交验收”。在这个链条里最被看重、最能体现产出量的环节是“写代码”。谁的代码写得多、写得快、写得稳谁的价值就容易被看见。AI 出现之后这个链条的产出重心发生了明显转移。写代码这个动作本身被大幅压缩而“拆任务”变成了最关键的一环。如果你只是把需求原封不动地丢给 AI它给出的一定是通用答案但如果你能把需求拆成“输入是什么、输出是什么、处理逻辑分几步、边界条件有哪些、失败情况怎么处理、性能要求是多少”AI 就能给你一份接近可直接上线的代码。这个差距不是“会不会用 AI”的差距而是“能不能定义好任务”的差距。我把这个过程称为从“命令执行者”到“需求定义者”的转变。在实际操作中这个转变表现为需求下来之后你不会立刻打开对话窗口让 AI 写代码而是先写一段结构化需求说明。你甚至会像维护代码一样维护这份需求说明把它放在项目仓库里每次 AI 辅助开发之前先更新它。这个习惯看起来增加了“额外工作量”但它恰恰是 AI 时代最值得投入的时间。2.2 上下文管理AI 时代的核心工程能力大模型本身有两个固有约束知识截止时间有限上下文窗口有限。即使是最新的模型也不可能无限记住你之前聊过的所有细节。这就带来一个很现实的工程问题你在对话窗口里和 AI 越聊越长前面说过的关键设定可能在某个节点被“遗忘”于是 AI 的回答开始偏离方向。处理这个问题的能力就是我前面提到的上下文管理能力。工程上通常有三种做法。第一种把关键信息写进提示词模板。不要依赖 AI 记住你上一条说过什么每次提问都把关键背景、约束、文件路径、输入输出格式写清楚。宁可让提示词显得“啰嗦”也好过让模型靠猜。第二种把项目知识做成独立文档。例如 README、设计文档、接口说明、数据字典在需要的时候作为参考资料加入对话。这样既减轻上下文窗口的压力也方便团队复用。第三种构建外部知识库通过检索增强生成RAG的方式让 AI 只从你指定的文档中获取项目信息而不是依靠模型内部记忆去猜测业务逻辑。你会发现这种能力在过去可能被归入“文档能力”或“架构能力”的范畴但在 AI 时代它变成了每个使用 AI 的人都应该具备的基本功。谁能用更少的上下文传递更准确的信息谁就能从 AI 那里获得更高质量的产出。2.3 验证与迭代把“幻觉”挡在生产环境之外大模型生成内容存在幻觉问题这是当前技术路线下的已知特性。幻觉在代码场景里表现为AI 使用了不存在的 API、虚构了方法签名、给出了看似合理但无法编译的代码或者代码可以运行但结果完全错误。应对幻觉唯一可靠的方式是建立“验证闭环”。AI 生成代码不是终点而是起点。你需要做这几件事本地运行验证、编写边界测试、用真实业务数据测试、检查依赖版本是否真实存在、对关键业务逻辑做代码评审。在能力模型层面这意味着即使你不亲手写每一行代码你也必须能看懂代码在做什么知道它为什么可能出问题以及出问题时如何定位。这不是“AI 取代程序员”的问题而是“程序员的角色从代码生产者变成代码验证者和管理者”的问题。谁先适应这个角色转变谁就能在 AI 时代拿到更多主动。3. 工具链与环境准备3.1 AI 辅助开发工具现状在动手实操前先梳理一下当前 AI 辅助开发的常见工具形态。以这两年的工具发展来看大致可以分为三类。第一类是对话式 AI 助手。你直接在聊天框里提问适合生成思路、解释代码、写测试用例、整理文档。第二类是 IDE 内嵌的 AI 编程工具比如 Cursor、Trae、GitHub Copilot 等它们能在编辑器里完成代码补全、代码生成、重构、解释等操作是目前开发效率提升最明显的场景。第三类是本地部署大模型通过 Ollama、LM Studio 这类工具在本地拉起模型服务适合对数据安全要求较高、需要离线使用的场景。这些工具各有侧重但有一个共同趋势接口层越来越标准化。目前很多模型服务都提供 OpenAI 兼容的 API 格式这意味着你可以用同一套 SDK 代码在本地模型和云端模型之间切换而不需要为每个服务商单独写一套适配层。如果你使用 Java 技术栈Spring AI 也提供了类似的抽象把不同大模型厂商的接口统一成 Spring 风格的 API方便在 Spring Boot 工程里接入 AI 能力。本文的实战案例会用到这个特性先用本地模型把流程跑通再替换成在线模型核心代码不需要大改。3.2 环境准备与版本说明由于不同环境的系统配置差异比较大这里先说明本文示例的运行环境约束。操作系统Windows 10/11、macOS 或主流 Linux 发行版都可以。Python 版本需要 3.9 及以上。开发工具VS Code 或任意主流 IDE安装 Python 插件即可。核心依赖streamlit、openai。模型服务可以使用本地部署的 Ollama 提供 OpenAI 兼容接口也可以替换为任意兼容接口的在线大模型平台。如果你的 Python 环境还比较干净建议先创建一个虚拟环境避免依赖冲突。后面章节的命令都以虚拟环境为前提具体的 Python 版本和依赖版本建议以你本机环境为准本文的示例重点演示配置思路和实现方式。3.3 安全与合规红线在正式开始写代码之前我要先强调一条安全红线不要把未脱敏的客户数据、个人隐私、公司业务机密原样发送给任何在线 AI 服务。AI 辅助开发的正确姿势是使用模拟数据、脱敏后的示例、不含敏感信息的代码逻辑去提问。如果项目确实涉及敏感数据优先考虑本地部署模型确保数据不出内网。这是一条最低成本的安全底线也是工程落地时最容易被忽略、一旦出事代价最高的细节。4. 实战用 AI 打造一个“提问力训练器”4.1 需求定义先定义再编码为了演示前面讲的能力模型我们做一个名为“提问力训练器”的小工具。它的业务背景是很多同学以为“会用 AI”等于“会提问”但实际上大部分人发给 AI 的需求是模糊的、缺少背景的、没有约束的。这个工具要解决的问题是在你把一段需求发给真正的 AI 之前先让本工具帮你评估这段需求的完整度并给出改进建议。功能需求清单如下用户输入一段准备发给 AI 的提问或需求文本。工具从“背景、目标、约束、参考、输出格式”五个维度评估完整度。输出总分、各维度命中情况、具体的改进建议。如果用户已经配置模型 API可以调用大模型做更智能的语义评估。技术选型上我选择 Python Streamlit。Streamlit 适合快速搭建数据处理类的小工具只需要写一个 Python 文件就能获得完整的 Web 界面对初学者很友好也方便后续扩展。这个需求定义过程本身就是一次“提问力”训练我们把“做一个评估工具”这个模糊想法拆成了输入、输出、评估维度、扩展方向。先定义清楚再让 AI 生成代码效率会高很多。4.2 项目结构设计项目的目录结构设计如下。prompt-trainer/ ├── app.py # Streamlit 主程序 ├── prompt_evaluator.py # 规则版评估逻辑 ├── model_eval.py # 模型版评估逻辑可选增强 ├── requirements.txt # 依赖清单 └── .env.example # 环境变量示例这个结构足够简单同时保持了核心逻辑与界面层的分离。prompt_evaluator.py 负责规则判断app.py 负责界面展示model_eval.py 负责接入大模型的增强评估。后面如果要扩展新的评估维度只需要修改 prompt_evaluator.py 里的配置不需要动界面层。4.3 让 AI 生成第一版代码现在演示真正“让 AI 辅助开发”的过程。我把下面这段提示词发给 AI请帮我写一个 Python 脚本做一个“提问完整度评估器”。 输入是一段用户发给 AI 的提问文本。 要求从“背景、目标、约束、参考、输出格式”五个维度判断该提问是否包含这些信息。 每个维度命中加 20 分满分 100。 最后输出总分、每个维度是否命中、以及对缺失维度的改进建议。 另外再判断一下文本中是否包含具体数字、是否包含明确的问题词。 不依赖第三方 API使用纯 Python 实现。这段提示词本身就包含了我对“问题定义”的思考我明确了输入、输出、评估维度、评分规则和限制条件。注意我没有让 AI 替我决定“评估维度”因为这是业务判断属于人的职责。AI 生成的代码可能需要微调。比如它可能用简单关键词匹配无法理解复杂语义但这恰好是可以接受的这个工具的目标是引导用户补充信息而不是做精确的自然语言理解。先让规则版跑起来再考虑引入模型增强。4.4 核心代码解读下面是调整后的核心代码。文件prompt-trainer/prompt_evaluator.py# 文件路径prompt-trainer/prompt_evaluator.py 提问完整度评估器基于规则的关键词匹配版本。 import re from typing import Dict, List # 五个评估维度每个维度对应一组关键词 DIMENSIONS [ (背景, [背景, 上下文, 现状, 目前, 当前, 我们]), (目标, [目标, 目的, 希望, 实现, 完成, 得到]), (约束, [约束, 限制, 不要, 不允许, 时间, 预算, 环境]), (参考, [参考, 示例, 例如, 比如, 类似, 数据结构]), (输出, [输出, 格式, 返回, json, 表格, 列表, 打印]), ] def evaluate_prompt(text: str) - Dict: 返回评分结果字典。 score 0 details: List[Dict] [] total len(DIMENSIONS) for name, keywords in DIMENSIONS: hit any(kw.lower() in text.lower() for kw in keywords) if hit: score 1 details.append({维度: name, 命中: True, 建议: }) else: details.append({ 维度: name, 命中: False, 建议: f建议补充{name}信息例如……, }) has_number bool(re.search(r\d, text)) has_question any(q in text for q in [, ?, 怎么, 怎样, 如何]) return { 总分: round(score / total * 100, 1), 维度详情: details, 包含具体数字: has_number, 包含明确问题: has_question, } def eval_to_text(result: Dict) - str: 格式化评估结果为纯文本方便界面展示。 lines AI时代什么能力更值钱？从提问力到上下文管理
最近 AI 辅助编程几乎成了绕不开的话题。身边不少同学问我现在 AI 都能自动生成代码了我还要不要花几个月去学某个框架万一学完就贬值了怎么办这个问题背后其实是同一个困惑——AI 时代到底什么能力才真正值钱。恰好最近看到关于 Notion 产品负责人的一期讨论核心观点一直在我脑子里转AI 把“会做”的门槛降下来了但把“知道该做什么、做到什么程度算好、怎么验证做对了”的门槛抬高了。换句话说比“技能”更值钱的是定义问题的能力、做出判断的能力以及管理上下文的能力。这篇文章不打算只聊观点。我会把这个判断翻译成一套可以在工程里落地的能力模型再通过一个完整的实战项目“提问力训练器”演示这些能力如何具体发挥作用最后整理 AI 辅助开发过程中的高频问题、排查思路和工程建议。无论你是产品、开发、测试还是数据方向的同学只要日常会接触 AI 工具这篇文章应该都能带来一些可落地的参考。1. 技能贬值时代什么在增值1.1 Notion 产品负责人观点的核心解读先补充一点背景。Notion 本身是一个重度 AI 化的知识管理与协作产品它的 AI 能力覆盖了文档总结、内容生成、智能问答、知识检索等常见场景。它的产品负责人谈“AI 时代什么更值钱”并不是在理论层面讲抽象概念而是基于大量真实用户的使用习惯和数据反馈得出的判断。这个判断浓缩成一句话就是AI 正在把执行层面的“技能”变成人人都能低成本获得的基础能力但随之而来的是对问题定义、结果判断和上下文组织这三类元能力的需求大幅提升。把这句话翻译成工程师日常听得懂的话以前我们比拼的是熟练度谁更熟悉某个框架、谁更快写出某段逻辑、谁记住了更多 API 的用法谁在团队里就更“值钱”。现在 AI 可以在几秒钟内完成代码生成、接口调用、SQL 编写、文档整理熟练度的差距正在被快速抹平。但 AI 并不知道你为什么要做这个功能不知道你的业务约束是什么不知道你的用户是谁也不知道验收标准是什么。如果结果不对它更不知道应该往哪个方向修正。这些判断和决策仍然只能由人来完成。所以比技能更值钱的是你对问题的定义能力、对过程的判断能力、对上下文的组织能力。技能本身没有消失但它从“核心竞争力”降级成了“基础成本”。1.2 为什么技能在 AI 时代容易贬值这里需要先做一个区分我们讨论的“技能”是指执行层面的熟练操作比如“会用某个 ORM 框架”“记得住某个 IDE 的全部快捷键”“会写某种 SQL 方言”“能快速搭建一个 Spring Boot 工程”。这类技能有两个共同特点第一可以被标准化描述第二可以被重复执行。可标准化、可重复恰恰是 AI 最容易替代的两类特征。大模型通过海量代码和文档的训练已经把绝大多数标准写法的生成能力内化到了模型参数里。当“技能”可以以极低成本被获取时它就不再是稀缺资源自然也不再是个人溢价的核心来源。但反过来看真正稀缺的是那些无法被一句话标准化的能力理解一个模糊业务需求背后的真实目标在多个可行方案中结合约束条件做取舍判断 AI 生成的代码是否真的满足当前场景在模型输出明显不合理时知道往哪个方向纠偏。这些能力没有办法通过“背 API”获得它们需要在真实的业务判断、工程决策和复盘反思中慢慢积累。所以说技能贬值不是坏消息。它其实是在提醒我们把时间从“记忆和重复”中释放出来花到“定义和判断”上去。1.3 比技能更值钱的三类能力结合 Notion 产品负责人的观点再补上工程实践中的体感我把“更值钱的能力”归纳为三类。第一类提问力也叫问题定义能力。它指的是你能把一个模糊想法拆成背景、目标、约束、参考示例和可验证的验收标准。同样面对一个需求有的人只能对 AI 说“帮我写个登录功能”有的人能说清楚“这是一个内部管理系统的账号登录要求支持邮箱密码登录、验证码过期时间为 5 分钟、失败 5 次锁定账号、登录日志写入数据库参考现有 xx 项目的风格”。后者得到的代码质量通常比前者高一个数量级。第二类判断力也叫结果评估能力。AI 生成的内容不总是对的甚至会一本正经地给出不存在的 API。判断力就是你能快速识别输出是否符合需求、哪里存在逻辑漏洞、哪里可能是幻觉、哪些部分需要人工再验证。它建立在领域知识和对业务目标的理解之上。第三类上下文管理力也叫信息组织能力。大模型的上下文窗口是有限的它不会记住你上一句话之后的所有细节。你能不能在有限的上下文里把最关键的信息传递给 AI决定了 AI 输出的质量上限。把项目背景、历史决策、领域知识整理成 AI 能理解的上下文本身就是一种工程能力。这三类能力不是空中楼阁。接下来的章节我会把它们逐一还原成工程师的具体动作并用一个实战项目演示。你可以发现它们完全可以通过刻意练习来提升不需要等待什么重大机会从下一个需求描述、下一段提示词、下一次 AI 辅助编码开始就可以着手训练。2. 把观点翻译成可执行的能力模型2.1 从“命令执行者”到“需求定义者”过去很长一段时间开发者的日常是“接到需求 - 拆任务 - 写代码 - 提交验收”。在这个链条里最被看重、最能体现产出量的环节是“写代码”。谁的代码写得多、写得快、写得稳谁的价值就容易被看见。AI 出现之后这个链条的产出重心发生了明显转移。写代码这个动作本身被大幅压缩而“拆任务”变成了最关键的一环。如果你只是把需求原封不动地丢给 AI它给出的一定是通用答案但如果你能把需求拆成“输入是什么、输出是什么、处理逻辑分几步、边界条件有哪些、失败情况怎么处理、性能要求是多少”AI 就能给你一份接近可直接上线的代码。这个差距不是“会不会用 AI”的差距而是“能不能定义好任务”的差距。我把这个过程称为从“命令执行者”到“需求定义者”的转变。在实际操作中这个转变表现为需求下来之后你不会立刻打开对话窗口让 AI 写代码而是先写一段结构化需求说明。你甚至会像维护代码一样维护这份需求说明把它放在项目仓库里每次 AI 辅助开发之前先更新它。这个习惯看起来增加了“额外工作量”但它恰恰是 AI 时代最值得投入的时间。2.2 上下文管理AI 时代的核心工程能力大模型本身有两个固有约束知识截止时间有限上下文窗口有限。即使是最新的模型也不可能无限记住你之前聊过的所有细节。这就带来一个很现实的工程问题你在对话窗口里和 AI 越聊越长前面说过的关键设定可能在某个节点被“遗忘”于是 AI 的回答开始偏离方向。处理这个问题的能力就是我前面提到的上下文管理能力。工程上通常有三种做法。第一种把关键信息写进提示词模板。不要依赖 AI 记住你上一条说过什么每次提问都把关键背景、约束、文件路径、输入输出格式写清楚。宁可让提示词显得“啰嗦”也好过让模型靠猜。第二种把项目知识做成独立文档。例如 README、设计文档、接口说明、数据字典在需要的时候作为参考资料加入对话。这样既减轻上下文窗口的压力也方便团队复用。第三种构建外部知识库通过检索增强生成RAG的方式让 AI 只从你指定的文档中获取项目信息而不是依靠模型内部记忆去猜测业务逻辑。你会发现这种能力在过去可能被归入“文档能力”或“架构能力”的范畴但在 AI 时代它变成了每个使用 AI 的人都应该具备的基本功。谁能用更少的上下文传递更准确的信息谁就能从 AI 那里获得更高质量的产出。2.3 验证与迭代把“幻觉”挡在生产环境之外大模型生成内容存在幻觉问题这是当前技术路线下的已知特性。幻觉在代码场景里表现为AI 使用了不存在的 API、虚构了方法签名、给出了看似合理但无法编译的代码或者代码可以运行但结果完全错误。应对幻觉唯一可靠的方式是建立“验证闭环”。AI 生成代码不是终点而是起点。你需要做这几件事本地运行验证、编写边界测试、用真实业务数据测试、检查依赖版本是否真实存在、对关键业务逻辑做代码评审。在能力模型层面这意味着即使你不亲手写每一行代码你也必须能看懂代码在做什么知道它为什么可能出问题以及出问题时如何定位。这不是“AI 取代程序员”的问题而是“程序员的角色从代码生产者变成代码验证者和管理者”的问题。谁先适应这个角色转变谁就能在 AI 时代拿到更多主动。3. 工具链与环境准备3.1 AI 辅助开发工具现状在动手实操前先梳理一下当前 AI 辅助开发的常见工具形态。以这两年的工具发展来看大致可以分为三类。第一类是对话式 AI 助手。你直接在聊天框里提问适合生成思路、解释代码、写测试用例、整理文档。第二类是 IDE 内嵌的 AI 编程工具比如 Cursor、Trae、GitHub Copilot 等它们能在编辑器里完成代码补全、代码生成、重构、解释等操作是目前开发效率提升最明显的场景。第三类是本地部署大模型通过 Ollama、LM Studio 这类工具在本地拉起模型服务适合对数据安全要求较高、需要离线使用的场景。这些工具各有侧重但有一个共同趋势接口层越来越标准化。目前很多模型服务都提供 OpenAI 兼容的 API 格式这意味着你可以用同一套 SDK 代码在本地模型和云端模型之间切换而不需要为每个服务商单独写一套适配层。如果你使用 Java 技术栈Spring AI 也提供了类似的抽象把不同大模型厂商的接口统一成 Spring 风格的 API方便在 Spring Boot 工程里接入 AI 能力。本文的实战案例会用到这个特性先用本地模型把流程跑通再替换成在线模型核心代码不需要大改。3.2 环境准备与版本说明由于不同环境的系统配置差异比较大这里先说明本文示例的运行环境约束。操作系统Windows 10/11、macOS 或主流 Linux 发行版都可以。Python 版本需要 3.9 及以上。开发工具VS Code 或任意主流 IDE安装 Python 插件即可。核心依赖streamlit、openai。模型服务可以使用本地部署的 Ollama 提供 OpenAI 兼容接口也可以替换为任意兼容接口的在线大模型平台。如果你的 Python 环境还比较干净建议先创建一个虚拟环境避免依赖冲突。后面章节的命令都以虚拟环境为前提具体的 Python 版本和依赖版本建议以你本机环境为准本文的示例重点演示配置思路和实现方式。3.3 安全与合规红线在正式开始写代码之前我要先强调一条安全红线不要把未脱敏的客户数据、个人隐私、公司业务机密原样发送给任何在线 AI 服务。AI 辅助开发的正确姿势是使用模拟数据、脱敏后的示例、不含敏感信息的代码逻辑去提问。如果项目确实涉及敏感数据优先考虑本地部署模型确保数据不出内网。这是一条最低成本的安全底线也是工程落地时最容易被忽略、一旦出事代价最高的细节。4. 实战用 AI 打造一个“提问力训练器”4.1 需求定义先定义再编码为了演示前面讲的能力模型我们做一个名为“提问力训练器”的小工具。它的业务背景是很多同学以为“会用 AI”等于“会提问”但实际上大部分人发给 AI 的需求是模糊的、缺少背景的、没有约束的。这个工具要解决的问题是在你把一段需求发给真正的 AI 之前先让本工具帮你评估这段需求的完整度并给出改进建议。功能需求清单如下用户输入一段准备发给 AI 的提问或需求文本。工具从“背景、目标、约束、参考、输出格式”五个维度评估完整度。输出总分、各维度命中情况、具体的改进建议。如果用户已经配置模型 API可以调用大模型做更智能的语义评估。技术选型上我选择 Python Streamlit。Streamlit 适合快速搭建数据处理类的小工具只需要写一个 Python 文件就能获得完整的 Web 界面对初学者很友好也方便后续扩展。这个需求定义过程本身就是一次“提问力”训练我们把“做一个评估工具”这个模糊想法拆成了输入、输出、评估维度、扩展方向。先定义清楚再让 AI 生成代码效率会高很多。4.2 项目结构设计项目的目录结构设计如下。prompt-trainer/ ├── app.py # Streamlit 主程序 ├── prompt_evaluator.py # 规则版评估逻辑 ├── model_eval.py # 模型版评估逻辑可选增强 ├── requirements.txt # 依赖清单 └── .env.example # 环境变量示例这个结构足够简单同时保持了核心逻辑与界面层的分离。prompt_evaluator.py 负责规则判断app.py 负责界面展示model_eval.py 负责接入大模型的增强评估。后面如果要扩展新的评估维度只需要修改 prompt_evaluator.py 里的配置不需要动界面层。4.3 让 AI 生成第一版代码现在演示真正“让 AI 辅助开发”的过程。我把下面这段提示词发给 AI请帮我写一个 Python 脚本做一个“提问完整度评估器”。 输入是一段用户发给 AI 的提问文本。 要求从“背景、目标、约束、参考、输出格式”五个维度判断该提问是否包含这些信息。 每个维度命中加 20 分满分 100。 最后输出总分、每个维度是否命中、以及对缺失维度的改进建议。 另外再判断一下文本中是否包含具体数字、是否包含明确的问题词。 不依赖第三方 API使用纯 Python 实现。这段提示词本身就包含了我对“问题定义”的思考我明确了输入、输出、评估维度、评分规则和限制条件。注意我没有让 AI 替我决定“评估维度”因为这是业务判断属于人的职责。AI 生成的代码可能需要微调。比如它可能用简单关键词匹配无法理解复杂语义但这恰好是可以接受的这个工具的目标是引导用户补充信息而不是做精确的自然语言理解。先让规则版跑起来再考虑引入模型增强。4.4 核心代码解读下面是调整后的核心代码。文件prompt-trainer/prompt_evaluator.py# 文件路径prompt-trainer/prompt_evaluator.py 提问完整度评估器基于规则的关键词匹配版本。 import re from typing import Dict, List # 五个评估维度每个维度对应一组关键词 DIMENSIONS [ (背景, [背景, 上下文, 现状, 目前, 当前, 我们]), (目标, [目标, 目的, 希望, 实现, 完成, 得到]), (约束, [约束, 限制, 不要, 不允许, 时间, 预算, 环境]), (参考, [参考, 示例, 例如, 比如, 类似, 数据结构]), (输出, [输出, 格式, 返回, json, 表格, 列表, 打印]), ] def evaluate_prompt(text: str) - Dict: 返回评分结果字典。 score 0 details: List[Dict] [] total len(DIMENSIONS) for name, keywords in DIMENSIONS: hit any(kw.lower() in text.lower() for kw in keywords) if hit: score 1 details.append({维度: name, 命中: True, 建议: }) else: details.append({ 维度: name, 命中: False, 建议: f建议补充{name}信息例如……, }) has_number bool(re.search(r\d, text)) has_question any(q in text for q in [, ?, 怎么, 怎样, 如何]) return { 总分: round(score / total * 100, 1), 维度详情: details, 包含具体数字: has_number, 包含明确问题: has_question, } def eval_to_text(result: Dict) - str: 格式化评估结果为纯文本方便界面展示。 lines