从“做事”到“设计问题”——AI时代，什么才是你的核心竞争力？
过去十年，我们强调“执行力”，强调“把事情做成”。程序员写代码、运营做活动、设计师出图——这些“做事”的能力，构成了职业价值的核心。
转眼间，AI来了。它写代码比你快，做图比你稳，写文案比你流畅。于是很多人开始焦虑：如果AI什么都能干，我们还能干什么？
答案其实藏在问题里：当AI学会“做事”，人类必须学会“设计问题”。
这篇文章将深入探讨这一转变，并给出具体的技术实践路径。
一、为什么“设计问题”比“解决问题”更重要？
在传统的软件开发中，我们遵循“需求-设计-编码-测试”的线性流程。核心能力在于编码——也就是“做事”。
但AI（尤其是大语言模型，如GPT-4、Claude）的出现，彻底改变了这个等式。AI可以瞬间完成编码、写作、数据分析等执行层工作。它像一个超级实习生，执行力极强，但前提是——你必须告诉它做什么，以及怎么做。
这就带来一个根本性的转变：价值重心从“执行”上移到“定义”。
- 执行者：被给定任务，完成它。
- 问题设计者：定义任务的目标、边界、评估标准，甚至分解出AI能理解的任务单元。
统计显示，在使用Copilot或ChatGPT进行开发时，一个精心设计的提示词（Prompt） 可以让输出质量提升数倍。而设计这个提示词的过程，本身就是“设计问题”。
二、设计问题的三层能力模型
我们可以把“设计问题”拆解为三个层次，每一层都对应着不同的技术实践。
1. 第一层：精准提问
这是最基础的能力。很多人抱怨AI“不听话”，往往是提问太模糊。
错误提问：
“帮我写一个登录功能。”
正确提问：
“请用Python Flask编写一个基于JWT的用户登录接口。要求：
- 使用SQLite作为数据库，用户表包含username和password_hash。
- 密码使用bcrypt加密存储。
- 登录成功后返回access_token，有效期30分钟。
- 提供错误处理：用户名不存在返回404，密码错误返回401。”
技术要点：
- 明确上下文：语言、框架、数据库。
- 定义输入输出：API的请求格式和响应格式。
- 设定约束：安全性、性能、可维护性要求。
代码示例： 将上述Prompt交给AI，它可能会生成如下代码（简化版）：
from flask import Flask, request, jsonify
import jwt
import bcrypt
import sqlite3
from datetime import datetime, timedelta
app = Flask(__name__)
app.config['SECRET_KEY'] = 'your-secret-key'
def get_db():
conn = sqlite3.connect('users.db')
return conn
@app.route('/login', methods=['POST'])
def login():
data = request.get_json()
username = data.get('username')
password = data.get('password')
conn = get_db()
cursor = conn.cursor()
cursor.execute("SELECT password_hash FROM users WHERE username=?", (username,))
row = cursor.fetchone()
conn.close()
if not row:
return jsonify({"error": "User not found"}), 404
if not bcrypt.checkpw(password.encode('utf-8'), row[0]):
return jsonify({"error": "Invalid password"}), 401
token = jwt.encode({
'username': username,
'exp': datetime.utcnow() + timedelta(minutes=30)
}, app.config['SECRET_KEY'], algorithm='HS256')
return jsonify({"access_token": token}), 200
你能看出来吗？这段代码几乎可以“拿来即用”。而这一切，只因为你问了一个好问题。
2. 第二层：拆解复杂问题
当需求复杂时，你不能指望一个Prompt解决所有。你需要将大问题拆解成小问题。
经典案例：构建一个RAG（检索增强生成）问答系统。
直接问“帮我写一个RAG系统”通常效果很差。你需要拆解：
- 文档加载模块：支持PDF、TXT、网页。
- 文本分块模块：按段落或固定长度切分，并保留上下文。
- 向量化模块：使用Embedding模型将文本转为向量。
- 检索模块：基于向量相似度（如余弦相似度）召回相关文本块。
- 生成模块：将检索结果作为上下文，交给LLM生成答案。
实践技巧： 为每个模块编写独立的Prompt，最后再让AI整合。
# 伪代码：模块化调用AI
modules = [
"请用LangChain写一个PDF文档加载器，返回Document列表。",
"请写一个文本分块器，使用RecursiveCharacterTextSplitter，块大小为500，重叠50。",
"请用OpenAI Embeddings将文档向量化，并存入Chroma向量数据库。",
"请写一个检索函数，给定查询，返回Top-3最相关的文档块。",
"请写一个生成函数，将检索结果和用户问题组合成Prompt，调用GPT-4生成答案。"
]
for prompt in modules:
response = ai_model.generate(prompt)
# 收集并整合代码
这种“分治”思维，是架构师的核心能力，在AI时代变得更加重要。
3. 第三层：定义评估标准与反馈闭环
AI输出不一定完美。你需要设计如何评估AI的输出，并建立反馈机制。
示例：评估AI生成的代码质量
不要只满足于“它能跑”。设计一个评估清单：
- 安全性：是否存在SQL注入、XSS风险？
- 性能：是否有不必要的循环或数据库查询？
- 可读性：命名是否规范？是否有注释？
- 可维护性：是否遵循了单一职责原则？
代码示例：自动化代码审查Prompt
review_prompt = f"""
请对以下Python代码进行审查，重点关注：
1. 安全性：检查是否存在SQL注入（使用参数化查询了吗？）
2. 性能：是否有可以优化的地方（如循环内数据库查询）？
3. 代码风格：是否符合PEP 8规范？
4. 错误处理：是否有遗漏的异常捕获？
代码：
{generated_code}
请以Markdown表格形式输出审查结果，每行包含：问题类型、严重程度（高/中/低）、具体位置、修改建议。
"""
通过这种方式，你不再是被动接受AI的输出，而是主动设计了一个评估系统来驾驭AI。
三、从“做事”到“设计问题”的工作流重构
理解了上述三层能力，我们可以重新定义AI时代的工作流：
传统工作流（执行者视角）：
- 接到需求
- 思考实现
- 写代码/做设计
- 测试
- 交付
AI时代工作流（问题设计者视角）：
- 定义问题：明确目标、约束、输入输出格式。
- 拆解任务：将大问题分解为AI可理解的子任务。
- 设计Prompt：为每个子任务编写高质量的提示词。
- 执行与评估：运行AI生成，并使用预设标准进行评估。
- 迭代优化：根据评估结果，调整Prompt或任务分解方式。
- 整合交付：将AI生成的模块整合成完整解决方案。
关键变化：你的时间不再花在“写代码”上，而是花在“定义、拆解、评估”上。这些正是“设计问题”的核心。
四、实际案例：用AI构建一个数据看板
假设你需要一个实时数据看板，展示网站访问量。传统做法需要写前端、后端、数据库。
作为问题设计者，你的Prompt可以是：
“请用Python Dash框架构建一个实时数据看板。要求：
- 数据源：模拟生成随机访问量数据，每秒更新一次。
- 展示内容：一个折线图显示过去60秒的访问量趋势，一个数字卡片显示总访问量。
- 样式：使用Bootstrap主题，深色背景。
- 代码结构：将数据生成、布局、回调函数分文件存放。
- 提供一键启动脚本。”
AI生成代码后，你只需要：
- 评估：检查数据更新逻辑是否正确？性能是否达标？
- 调整：如果折线图刷新太频繁，修改Prompt为“每2秒更新一次”。
- 扩展：增加新需求，如“添加一个下拉菜单选择不同数据维度”。
整个过程，你几乎没有写一行代码，但你看板做成了。你的价值体现在你如何定义这个看板，而不是如何画那个折线图。
五、结语：成为“问题设计师”
AI时代，最稀缺的能力不是“做得快”，而是“想得对”。
- 会提问的人，让AI产出高质量结果。
- 会拆解的人，让AI解决复杂系统问题。
- 会评估的人，让AI输出可靠、可维护。
从今天开始，试着改变你的工作习惯：
- 写代码前，先写Prompt。
- 遇到复杂需求，先拆解成子问题。
- 拿到AI输出，先设计评估维度。
当你从“做事的人”转变为“设计问题的人”，你会发现：AI不是取代你，而是放大了你的价值。
因为，能定义问题的人，永远比能解决问题的人更稀缺。
下一步行动： 打开你的AI工具，尝试用本文提到的三层模型，重新设计你手头的一个任务。你会发现，同样的工具，不同的提问方式，结果天差地别。这就是核心竞争力的差距。