AI 把实现变快以后，问题定义更重要了Problem framing matters more when AI makes building faster
生成代码缩短了实现时间，却没有替我们判断用户、场景和成功标准。这篇文章记录我在动手前怎样检查一个问题是否值得做。Code generation shortens implementation time. It cannot decide who the user is, where the problem appears, or which result would count as success.
现在做出一个能运行的 AI 功能，比过去快得多。
我可以在短时间内搭出页面、接上模型、补一条工作流。速度带来一种错觉：只要 Demo 能跑，产品就已经向前走了。可运行只证明实现链路成立。用户是否需要它、会在什么场景使用、愿不愿意改变原来的习惯，仍然没有答案。
我在几个求职和 Agent 项目里反复遇到这个问题。功能越容易增加，我越需要在动手前写清楚要验证什么。
一个宽泛目标会制造很多功能
“做一个 AI 求职助手”听起来像一个方向，无法直接指导产品决策。
它可能指向简历生成、岗位筛选、面试训练，也可能想覆盖整段求职流程。每个方向面对的用户时刻、数据风险和成功标准都不同。如果我没有先缩小问题，功能列表很快就会变长，最后却无法判断哪项功能产生了价值。
JobMatch 和 JobLoop 让我看到了两种不同边界。
JobMatch 聚焦岗位筛选。用户已经有职位信息，需要更快排除不合适的选项，同时不希望把全部求职记录交给外部服务。这个问题适合围绕筛选规则、数据边界和结果解释展开。
JobLoop 关注更长的求职过程。它需要处理经历整理、岗位匹配和面试准备之间的衔接。这里的难点变成了阶段之间如何共享上下文，以及用户怎样理解下一步。
两个项目都和求职有关，但它们需要不同的产品结构。一个宽泛标签无法替代场景定义。
我先写下五个答案
开始实现前，我会用五个问题约束想法：
- 谁正在遇到这个问题？ 我需要描述具体的人和状态，不能只写“求职者”或“开发者”。
- 问题在哪个时刻出现？ 同一个人准备简历和筛选岗位时，需要的帮助并不相同。
- 他现在怎样处理？ 表格、搜索、复制粘贴和放弃都属于现有方案。
- 现有方案带来什么成本？ 时间、理解负担、隐私风险和出错概率需要分开看。
- 什么结果能支持继续投入？ 我会提前决定要观察的行为或证据。
如果这些答案仍然模糊，我可以先访谈、查看真实流程或做一个低成本原型。此时增加模型能力通常不会让问题变清楚。
用一个问题定义 MVP
功能清单容易让团队忙起来，验证问题能帮助团队作出决定。
以岗位筛选为例，第一版可以只验证：用户能否用少量规则稳定缩小职位范围，并理解每个结果为什么保留或排除。
这个问题会直接影响范围。第一版需要规则输入、结果展示和解释机制。完整账户系统、复杂推荐算法和自动投递可以等待。范围缩小后，开发和复盘都更清楚，因为每项工作都服务于同一个判断。
我也会写下停止条件。如果用户无法理解结果，或者规则输入本身比手动筛选更费力，我需要调整交互或重新检查问题，不能用更多功能掩盖它。
AI 适合加速已经明确的部分
模型擅长生成、归纳和转换表达。它也能帮助我快速比较方案、补齐测试和制作原型。这些能力建立在清楚的任务边界上。
当目标只有“做得更智能”时，模型会生成很多看似合理的可能性。我仍然需要决定哪些可能性属于用户场景，哪些只是技术展示。
我现在把问题定义看成一份可检查的工作产物。它至少要说明用户、场景、约束和验证方式。项目推进后，我会用运行结果和反馈修改这份定义。
动手前的检查表
- 我能否用一句话说清谁在什么时刻遇到了什么困难？
- 我是否看过用户现在使用的替代方案？
- 第一版只需要回答哪个产品问题？
- 哪些数据会进入系统，谁能看到它们？
- 哪项证据会支持继续投入，哪项证据会让我停下来？
实现速度还会继续提高。省下来的时间可以拿来理解场景、缩小范围，也可以拿来堆积更多功能。我希望自己的项目选择前一种用法。
Building a working AI feature takes less time than it used to.
I can assemble an interface, connect a model, and add a workflow within a short development cycle. That speed creates a tempting shortcut: if the demo runs, the product must be making progress. A runnable demo only confirms that the implementation path works. It says little about whether someone needs it, where they would use it, or whether they would change their current behavior.
I have met this problem across several job-search and agent projects. As features become cheaper to add, I need a clearer reason for adding each one.
A broad goal produces a broad feature list
“Build an AI job-search assistant” describes a field, not a product decision.
The idea could lead to résumé writing, job filtering, interview practice, or a system that covers the whole search process. Each direction serves a different moment and carries different data risks. Without a narrower problem, the feature list grows while the success criteria remain unclear.
JobMatch and JobLoop helped me see two distinct boundaries.
JobMatch focuses on filtering. The user already has job information and needs a faster way to remove poor fits without handing a complete search history to another service. That problem calls for clear filters, controlled data handling, and explanations for each result.
JobLoop covers a longer journey. It connects experience capture, job matching, and interview preparation. Its product questions concern continuity between stages and how the user understands the next useful action.
Both projects relate to job search. They still require different product structures. A category label cannot replace a defined situation.
Five answers before implementation
I use five questions to constrain an idea:
- Who is experiencing the problem? “Job seeker” or “developer” is too broad. I need a person in a specific state.
- At which moment does it appear? Preparing a résumé and filtering open roles create different needs.
- How does the person handle it today? Spreadsheets, search, copy and paste, and abandonment are all existing solutions.
- What does the current method cost? Time, cognitive load, privacy exposure, and error risk need separate attention.
- Which result would justify more investment? I choose the behavior or evidence before I build.
When these answers remain vague, an interview, a workflow observation, or a low-cost prototype may be more useful than another model capability.
Define the MVP with one decision
A feature list creates activity. A validation question creates a decision.
For job filtering, a first version might test whether a user can reduce a large set of roles with a few rules and understand why each result was kept or removed.
That question shapes the scope. The version needs rule input, results, and explanations. Accounts, complex recommendations, and automatic applications can wait. Development becomes easier to review because each part supports the same judgment.
I also write down a stopping condition. If users cannot understand the results, or if entering the rules costs more effort than manual filtering, I need to revisit the interaction or the problem definition. More features would hide the issue.
AI accelerates the parts with clear boundaries
Models are useful for generation, summarization, and rewriting. They can also help compare approaches, expand tests, and build prototypes. These strengths work best inside a defined task.
“Make it smarter” produces many plausible options. I still need to decide which options belong to the user’s situation and which ones only demonstrate the technology.
I now treat problem framing as an inspectable project artifact. It should name the user, situation, constraints, and validation method. Runtime results and feedback can then revise it.
My pre-build checklist
- Can I describe who faces the problem and when it appears in one sentence?
- Have I examined the person’s current workaround?
- Which product question must the first version answer?
- Which data enters the system, and who can access it?
- Which evidence would support further work, and which evidence would make me stop?
Implementation will keep getting faster. I can spend the saved time understanding the situation and narrowing the scope, or I can spend it accumulating features. I want my projects to choose the first path.