你的 AI 编码智能体不需要更好的提示词,而是需要一个运行框架。
Your AI Coding Agent Doesn't Need a Better Prompt. It Needs a Harness.
我们发现了什么
你的 AI 编码智能体不需要更好的提示词。你的 AI 智能体说测试已经通过了。
- 来源:DEV Community(发现于 2026-11-12)
- 证据等级:C · 存在定价或订阅线索;有收费设计不等于已有收入。
- 商业模式:待核验
- 主题:开发者工具
- 初筛评分:14.9/100 · 收录 1 次
证据,比故事更重要。
规则清洗与初筛,未经人工商业核验。原文语境、实际客户和付费情况仍需自行验证。
引用与数字披露
来源类型(原作者自述/第三方测算/媒体转引)需采集端标注,本版尚未落字段。
- 作者
- 未标注
- 出处
- https://dev.to/holasoymalva/your-ai-coding-agent-doesnt-need-a-better-prompt-it-needs-a-harness-9ej
- 抓取日期
- 来源类型
- 未标注
- 币种
- 未标注
- 口径
- 未标注
- 披露主体
- 未标注
- 披露日期
- 未标注
中文辅助译文(全文)
你的 AI 编程代理刚刚宣布:
✅ 完成!一切都能正常运行。所有测试均已通过。
很好。小问题:你的项目根本没有任何测试。
于是你写一个更好的提示词。“再检查一遍你的工作。”“遵循最佳实践。”“像资深工程师一样行事。”你不如再加上“拜托了”,再给它一块饼干。
代理回答:“当然!”然后又把别的东西弄坏了。
这是我不受欢迎的观点:我们花了太多时间,试图为在糟糕的工程环境中工作的代理编写完美提示词。
更好的提示词会有帮助。但提示词无法取代测试、项目上下文、架构边界或真正的反馈闭环。
这就是 代理支撑工程 背后的理念:围绕编程代理设计环境,使其工作能够被引导、检查和纠正。
而且没错,我们正在构建一个。大约 15 分钟即可完成,使用 Node.js,无需付费 API,也不依赖任何 npm 包。该支撑框架可与现有编程代理配合使用,只要它能够读取文件并运行终端命令;我们不会再构建另一个代理框架。
你将构建:
AGENTS.md,用于说明仓库及其规则。- 一套失败的测试,用于定义“修复”意味着什么。
- 一道轻量级架构护栏。
- 一条命令(
npm run check),用于提供真实反馈。 - 在每个拉取请求上运行相同检查的 CI。
提示词工程 vs. 代理支撑工程
提示词说:“不要破坏现有功能。”
支撑框架说:“这些是回归测试。运行它们。”
提示词说:“遵循架构。”
支撑框架说:“阅读架构文档,这里有一项检查,会拒绝不允许的导入。”
提示词说:“确保它能正常工作。”
支撑框架说:“给我看退出码。”
这两者不是一回事。但也不是敌人:好的提示词告诉代理你想要什么;支撑框架则给它一个环境,让进展可观察、可验证。
任务 + 约束
|
v
编程代理 <----- 检查失败输出
| ^
v |
代码更改 --> npm run check
|
通过 / 失败
|
人工审查在这个流行词发展出自己的认证项目之前,先把它落到实处。
第 1 步:给代理一个值得修复的 bug
前置条件:Node.js 22+、Git,以及一个可访问本地仓库的编程代理(Codex、Claude Code 或任意同等工具)。你也可以全程手动完成这个练习。
mkdir agent-harness-lab && cd agent-harness-lab
npm init -y
mkdir -p src test scripts docs .github/workflows将 package.json 替换为:
{
"name": "agent-harness-lab",
"private": true,
"type": "module",
"engines": { "node": ">=22" },
"scripts": {
"test": "node --test",
"guardrails": "node scripts/guardrails.js",
"check": "npm run guardrails && npm test"
}
}创建 src/pricing.js:
export function calculateTotal(items, discountPercent = 0) {
const subtotal = items.reduce(
(sum, item) => sum + item.price * item.quantity,
0
);
return Math.round(
(subtotal * (1 - discountPercent / 100)) * 100
) / 100;
}看起来没问题,对吧?三条腿的椅子看起来也没问题,直到有人坐上去。
这个函数接受负数数量、NaN 价格和 120% 的折扣。我们要让这些失败无法被忽视。
第 2 步:让“完成”变得可执行
创建 test/pricing.test.js:
import test from 'node:test';
import assert from 'node:assert/strict';
import { calculateTotal } from '../src/pricing.js';
test('计算正常总额', () => {
assert.equal(calculateTotal([{ price: 12.5, quantity: 2 }]), 25);
});
test('应用有效折扣', () => {
assert.equal(calculateTotal([{ price: 100, quantity: 1 }], 15), 85);
});
test('拒绝负数数量', () => {
assert.throws(
() => calculateTotal([{ price: 10, quantity: -1 }]),
RangeError
);
});
test('拒绝超过 100% 的折扣', () => {
assert.throws(
() => calculateTotal([{ price: 10, quantity: 1 }], 120),
RangeError
);
});
test('拒绝非有限价格', () => {
assert.throws(
() => calculateTotal([{ price: NaN, quantity: 1 }]),
TypeError
);
});
test('不修改购物车', () => {
const items = [{ price: 10, quantity: 2 }];
const before = structuredClone(items);
calculateTotal(items);
assert.deepEqual(items, before);
});运行:
npm test预期结果:3 个测试通过,3 个失败。这是好消息。我们把一个模糊请求转换成了一个可度量的目标。
没错,这个示例使用 JavaScript 浮点数,以免偏离代理工作流这一重点。涉及真实金额时,请使用整数最小货币单位,或采用配有成文舍入规则的小数策略。
第 3 步:别再让代理猜你的仓库是如何运作的
在仓库根目录创建 AGENTS.md:
# 项目说明
## 上下文
- Node.js 22+、ESM,无运行时依赖。
- 定价逻辑:src/pricing.js
- 测试:test/pricing.test.js
- 架构说明:docs/architecture.md
## 规则
- 保留 calculateTotal(items, discountPercent = 0)。
- 不要为了让检查通过而修改测试或护栏。
- 未经批准,不要添加包。
- 不要访问机密信息,也不要部署、发布或推送更改。
- 将更改限定在任务范围内。
## 验证
- 运行:npm run check
- 报告实际结果,包括失败。
- 在声称完成之前审查 git diff。
## 完成定义
- 所需行为正常工作。
- npm run check 通过。
- 没有无关更改。
- 列出剩余风险,供人工审查。创建 docs/architecture.md:
# 架构
公开 API 为 calculateTotal(items, discountPercent = 0)。
生产代码位于 src/;测试位于 test/。
定价函数必须是纯函数,且不得执行 I/O。
无效输入必须抛出错误,而不是静默产生无意义的总额。这里有一个微妙之处:Codex 会将 AGENTS.md 识别为仓库指令文件,但代理产品各不相同。对于其他工具,请确认其约定,或明确告诉代理读取该文件。Markdown 文件名并不是心灵感应。
而且,这个文件只是指导,不是安全边界。如果代理有权删除生产资源,在 Markdown 中写“请不要”也无法撤销该权限。
第 4 步:在代码所在之处设置一些护栏
创建 scripts/guardrails.js:
import { readFileSync, readdirSync } from 'node:fs';
const pkg = JSON.parse(readFileSync('package.json', 'utf8'));
for (const field of ['dependencies', 'optionalDependencies', 'peerDependencies']) {
if (Object.keys(pkg[field] ?? {}).length) {
throw new Error(`${field} 在本实验室中不允许使用`);
}
}
for (const file of readdirSync('src').filter((f) => f.endsWith('.js'))) {
const source = readFileSync(`src/${file}`, 'utf8');
// 范围很窄的教学示例:src/*.js 中不允许导入。
if (/\b(?:import|require)\s*(?:\(|[{\'"*])/m.test(source)) {
throw new Error(`src/${file} 中存在不允许的导入`);
}
}
console.log('架构护栏检查通过。');它检查两项特定约束:没有声明的运行时依赖项,以及顶层 src/*.js 文件中没有明显的导入。它不是通用安全扫描器,而正则表达式也不是可靠的 JavaScript 解析器。对于正式项目,请使用 AST 感知的 lint 规则和依赖项策略。
现在运行:
npm run check护栏检查通过;三个行为测试仍然失败。这是支撑框架在履行职责,不是代理状态不佳。
第 5 步:给代理一份任务契约,而不是一场励志演讲
用你的编程代理打开仓库,然后粘贴:
编辑前先阅读 AGENTS.md 和 docs/architecture.md。
修复 src/pricing.js,使所有现有定价测试都通过。
约束:
- 保留 calculateTotal(items, discountPercent = 0)。
- 负数数量:RangeError。
- 0..100 之外的折扣:RangeError。
- 非有限价格:TypeError。
- 保持函数为纯函数。
- 仅修改 src/pricing.js。
- 不要安装依赖项或削弱测试。
运行 npm run check 并检查其实际输出。
如果失败,修复原因并重新运行,最多尝试 3 次。
除非命令成功,否则不要声称成功。
报告已更改文件、检查结果和剩余风险。注意变化之处:提示词仍然重要,但现在它指向的是一份独立契约。
一种可以通过测试的实现是:
export function calculateTotal(items, discountPercent = 0) {
if (!Array.isArray(items)) {
throw new TypeError('items 必须是数组');
}
if (!Number.isFinite(discountPercent) ||
discountPercent < 0 || discountPercent > 100) {
throw new RangeError('discountPercent 必须在 0 到 100 之间');
}
const subtotal = items.reduce((sum, item) => {
if (!item || typeof item !== 'object' || !Number.isFinite(item.price)) {
throw new TypeError('price 必须是有限值');
}
if (!Number.isInteger(item.quantity) || item.quantity < 0) {
throw new RangeError('quantity 必须是非负数');
}
if (item.price < 0) {
throw new RangeError('price 必须是非负数');
}
return sum + item.price * item.quantity;
}, 0);
return Math.round(subtotal * (1 - discountPercent / 100) * 100) / 100;
}自行检查:
npm run check
git diff --check
git diff应用该修复后的预期结果:6 个测试全部通过。测试通过并不能证明每一种可能的行为都正确,而且 git diff 仍需要人工审查。但至少我们现在讨论的是证据,而不是感觉。
有用的闭环是:
编辑 -> 运行检查 -> 读取真实失败信息 -> 修复 -> 再次运行
|
最多尝试 3 次后停止
并请求审查永远不断重试的代理并不自主。那是一种订阅续费策略。
第 6 步:让支撑框架脱离你的笔记本电脑后依然有效
创建 .github/workflows/check.yml:
name: 检查
on: [push, pull_request]
permissions:
contents: read
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm run check
- run: git diff --check打开一个拉取请求。现在,CI 会运行与本地代理相同的检查。
对于生产环境,请将第三方 GitHub Actions 固定到经过审查的提交 SHA,强制执行必需的检查和审查,并保护测试和护栏(例如使用 CODEOWNERS 和分支规则)。如果允许代理编辑一切,它就能通过削弱评估器,让自己的评估结果看起来是绿色的。
另外:请在适当受限的环境中运行代理执行的代码。对于破坏性操作,测试不能取代沙箱、权限控制或审批关卡。
那么,我们究竟获得了什么?
之前,你的质量策略是:
“请小心一点。”
现在你有了:
| 问题 | 支撑框架的响应 |
|---|---|
| 代理编造测试结果 | 运行 npm run check 并读取实际退出码 |
| 代理忘记项目约定 | AGENTS.md + 架构说明 |
| 代理引入不允许的导入 | 架构护栏检查失败 |
| 代理破坏行为 | 回归测试失败 |
| 代理过早宣布胜利 | CI 和人工审查仍是彼此独立的关卡 |
对于较长的任务,也可以使用一份简短的 docs/HANDOFF.md 来保留信息,其中包含目标、已更改文件、实际验证结果、阻塞项和下一步操作。不要粘贴整段聊天记录,然后把它叫作文档。
想知道这对你的 团队 是否有帮助?测量一下。
选取五个可比的任务。使用相同的模型、起始仓库状态、允许尝试次数和时间预算。比较 仅提示词 与 提示词 + 支撑框架。跟踪:
- 经核验的任务成功率。
- 人工审查耗时。
- 更改的无关文件数量。
- 修复尝试次数。
- Token/API 成本。
不要假装一个玩具示例证明了普遍的性能提升。本实验的目的在于演示这一机制,而不是制造一项基准测试。
令人不适的结论
提示词工程并没有消亡。但“写一个更好的提示词”并不是完整的软件工程策略。
如果不给代理测试、上下文或护栏,并赋予无限权限,它就能非常高效地失败。恭喜:你已经把混乱自动化了。
支撑框架会让失败清晰可见,并给代理一次结构化的恢复机会。这并不保证正确性,但给了你一种评估代理的方法。
目标不是一个自信地宣布以下内容的代理:
一切都已达到生产就绪状态!🚀
而是一套能够证明以下事实的工作流:
✓ 架构检查通过
✓ 6 个行为测试通过
✓ 合并前已审查更改
→ 已准备就绪,等待人工批准你的 AI 编程代理最近一次自信地弄坏了什么?更重要的是:哪一项自动检查原本能够捕获它?
请在评论中告诉我。我收集这些故事,就像有些人收集 Pokémon 一样。
延伸阅读:
译文由上游机器翻译生成,可能有误;判断请以英文原文为准。
英文原文(来源本站未改写)
Your AI coding agent just announced:
✅ Done! Everything works. All tests passed.
Excellent. Small problem: your project doesn't have any tests.
So you write a better prompt. “Double check your work.” “Follow best practices.” “Act like a senior engineer.” You might as well add “pretty please” and offer it a cookie.
The agent says “Absolutely!” and breaks something else.
Here's my unpopular opinion: we spend too much time trying to write perfect prompts for agents working inside terrible engineering environments.
A better prompt can help. But a prompt can't replace tests, project context, architectural boundaries, or an actual feedback loop.
That's the idea behind harness engineering: design the environment around a coding agent so its work can be guided, checked, and corrected.
And yes, we're building one. In about 15 minutes, with Node.js, no paid API, and no npm dependencies. The harness works with an existing coding agent that can read files and run terminal commands; we're not building another agent framework.
What you'll build:
AGENTS.mdto explain the repository and its rules.- A failing test suite that defines what “fixed” means.
- A lightweight architecture guardrail.
- One command (
npm run check) that provides real feedback. - CI that runs the same checks on every pull request.
Prompt engineering vs. harness engineering
A prompt says: “Don't break existing functionality.”
A harness says: “Here are the regression tests. Run them.”
A prompt says: “Stick to the architecture.”
A harness says: “Read the architecture docs, and here's a check that rejects forbidden imports.”
A prompt says: “Make sure it works.”
A harness says: “Show me the exit code.”
Not the same thing. Also, not enemies: a good prompt tells the agent what you want; a harness gives it an environment in which progress is observable and verifiable.
Task + constraints
|
v
Coding agent <----- failed check output
| ^
v |
Code changes --> npm run check
|
pass / fail
|
Human reviewLet's make that real before the buzzword develops its own certification program.
Step 1: Give the agent a bug worth fixing
Prerequisites: Node.js 22+, Git, and a coding agent with access to your local repository (Codex, Claude Code, or any equivalent). You can complete the entire exercise manually too.
mkdir agent-harness-lab && cd agent-harness-lab
npm init -y
mkdir -p src test scripts docs .github/workflowsReplace package.json with:
{
"name": "agent-harness-lab",
"private": true,
"type": "module",
"engines": { "node": ">=22" },
"scripts": {
"test": "node --test",
"guardrails": "node scripts/guardrails.js",
"check": "npm run guardrails && npm test"
}
}Create src/pricing.js:
export function calculateTotal(items, discountPercent = 0) {
const subtotal = items.reduce(
(sum, item) => sum + item.price * item.quantity,
0
);
return Math.round(
(subtotal * (1 - discountPercent / 100)) * 100
) / 100;
}Looks fine, right? So does a chair with three legs, until someone sits down.
This function accepts negative quantities, NaN prices, and 120% discounts. Let's make those failures impossible to ignore.
Step 2: Make “done” executable
Create test/pricing.test.js:
import test from 'node:test';
import assert from 'node:assert/strict';
import { calculateTotal } from '../src/pricing.js';
test('calculates normal totals', () => {
assert.equal(calculateTotal([{ price: 12.5, quantity: 2 }]), 25);
});
test('applies a valid discount', () => {
assert.equal(calculateTotal([{ price: 100, quantity: 1 }], 15), 85);
});
test('rejects negative quantities', () => {
assert.throws(
() => calculateTotal([{ price: 10, quantity: -1 }]),
RangeError
);
});
test('rejects discounts above 100%', () => {
assert.throws(
() => calculateTotal([{ price: 10, quantity: 1 }], 120),
RangeError
);
});
test('rejects non-finite prices', () => {
assert.throws(
() => calculateTotal([{ price: NaN, quantity: 1 }]),
TypeError
);
});
test('does not mutate the cart', () => {
const items = [{ price: 10, quantity: 2 }];
const before = structuredClone(items);
calculateTotal(items);
assert.deepEqual(items, before);
});Run:
npm testExpected result: 3 tests pass, 3 fail. That's good news. We've converted a vague request into a measurable target.
And yes, this example uses JavaScript floating point numbers to stay focused on agent workflows. For real money, use integer minor units or a decimal strategy with documented rounding rules.
Step 3: Stop making the agent guess how your repository works
Create AGENTS.md at the repository root:
# Project instructions
## Context
- Node.js 22+, ESM, no runtime dependencies.
- Pricing logic: src/pricing.js
- Tests: test/pricing.test.js
- Architecture notes: docs/architecture.md
## Rules
- Preserve calculateTotal(items, discountPercent = 0).
- Do not change tests or guardrails to make a check pass.
- Do not add packages without approval.
- Do not access secrets, deploy, publish, or push changes.
- Keep changes scoped to the task.
## Verification
- Run: npm run check
- Report the actual result, including failures.
- Review git diff before claiming completion.
## Definition of done
- Requested behavior works.
- npm run check passes.
- No unrelated changes.
- Remaining risks are listed for human review.Create docs/architecture.md:
# Architecture
The public API is calculateTotal(items, discountPercent = 0).
Production code belongs in src/; tests belong in test/.
The pricing function must be pure and must not perform I/O.
Invalid inputs must throw, not silently produce nonsense totals.One subtle point: Codex recognizes AGENTS.md as a repository instruction file, but agent products differ. For other tools, verify their convention or explicitly tell the agent to read the file. A markdown filename isn't telepathy.
And this file is guidance, not a security boundary. If an agent has permission to delete production resources, writing “please don't” in Markdown won't revoke that permission.
Step 4: Put some guardrails where the code lives
Create scripts/guardrails.js:
import { readFileSync, readdirSync } from 'node:fs';
const pkg = JSON.parse(readFileSync('package.json', 'utf8'));
for (const field of ['dependencies', 'optionalDependencies', 'peerDependencies']) {
if (Object.keys(pkg[field] ?? {}).length) {
throw new Error(`${field} are not allowed in this lab`);
}
}
for (const file of readdirSync('src').filter((f) => f.endsWith('.js'))) {
const source = readFileSync(`src/${file}`, 'utf8');
// Narrow teaching example: no imports in src/*.js.
if (/\b(?:import|require)\s*(?:\(|[{\'"*])/m.test(source)) {
throw new Error(`Unexpected import in src/${file}`);
}
}
console.log('Architectural guardrails passed.');This checks two specific constraints: no declared runtime dependencies and no obvious imports in top level src/*.js files. It is not a general security scanner, and regex is not a robust JavaScript parser. For serious projects, use AST aware lint rules and dependency policies.
Now run:
npm run checkThe guardrail passes; the three behavior tests still fail. That's the harness doing its job, not an agent having a bad day.
Step 5: Give the agent a task contract, not a motivational speech
Open the repository with your coding agent and paste:
Read AGENTS.md and docs/architecture.md before editing.
Fix src/pricing.js so all existing pricing tests pass.
Constraints:
- Preserve calculateTotal(items, discountPercent = 0).
- Negative quantities: RangeError.
- Discounts outside 0..100: RangeError.
- Non finite prices: TypeError.
- Keep the function pure.
- Change only src/pricing.js.
- Do not install dependencies or weaken tests.
Run npm run check and inspect its actual output.
If it fails, fix the cause and rerun, up to 3 attempts.
Do not claim success unless the command succeeds.
Report files changed, check results, and remaining risks.Notice what changed: the prompt is still important, but it now points to an independent contract.
A possible passing implementation is:
export function calculateTotal(items, discountPercent = 0) {
if (!Array.isArray(items)) {
throw new TypeError('items must be an array');
}
if (!Number.isFinite(discountPercent) ||
discountPercent < 0 || discountPercent > 100) {
throw new RangeError('discountPercent must be between 0 and 100');
}
const subtotal = items.reduce((sum, item) => {
if (!item || typeof item !== 'object' || !Number.isFinite(item.price)) {
throw new TypeError('price must be finite');
}
if (!Number.isInteger(item.quantity) || item.quantity < 0) {
throw new RangeError('quantity must be nonnegative');
}
if (item.price < 0) {
throw new RangeError('price must be nonnegative');
}
return sum + item.price * item.quantity;
}, 0);
return Math.round(subtotal * (1 - discountPercent / 100) * 100) / 100;
}Check it yourself:
npm run check
git diff --check
git diffExpected after applying that fix: all 6 tests pass. Passing tests don't prove every possible behavior is correct, and git diff still needs human review. But at least we're discussing evidence instead of vibes.
The useful loop is:
Edit -> Run checks -> Read real failure -> Fix -> Run again
|
Stop after 3 attempts
and request reviewAn agent that retries forever isn't autonomous. It's a subscription renewal strategy.
Step 6: Make the harness survive your laptop
Create .github/workflows/check.yml:
name: Check
on: [push, pull_request]
permissions:
contents: read
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm run check
- run: git diff --checkOpen a pull request. Now CI runs the same checks as your local agent.
For production use, pin third party GitHub Actions to vetted commit SHAs, enforce required checks and reviews, and protect tests and guardrails (for example with CODEOWNERS and branch rules). An agent can make its own evaluation look green by weakening the evaluator if you let it edit everything.
Also: run agent executed code in a suitably restricted environment. Tests don't replace sandboxing, permissions, or approval gates for destructive actions.
So what did we actually gain?
Before, your quality strategy was:
“Please be careful.”
Now you have:
| Problem | Harness response |
|---|---|
| Agent invents test results | Run npm run check and read the actual exit code |
| Agent forgets project conventions | AGENTS.md + architecture notes |
| Agent introduces forbidden imports | Architectural guardrail fails |
| Agent breaks behavior | Regression tests fail |
| Agent declares victory early | CI and human review remain separate gates |
You can also preserve longer tasks using a short docs/HANDOFF.md with the objective, files changed, real verification results, blockers, and next action. Don't paste an entire chat transcript and call it documentation.
Want to know whether this helps your team? Measure it.
Take five comparable tasks. Use the same model, starting repository state, allowed attempts, and time budget. Compare prompt-only versus prompt + harness. Track:
- Verified task success rate.
- Human review time.
- Unrelated files changed.
- Number of repair attempts.
- Token/API cost.
Avoid pretending a single toy example proves a universal performance gain. The point of this lab is to demonstrate the mechanism, not manufacture a benchmark.
The uncomfortable conclusion
Prompt engineering isn't dead. But “write a better prompt” is not a complete software engineering strategy.
If you give an agent no tests, no context, no guardrails, and unlimited permissions, it can fail very efficiently. Congratulations: you've automated chaos.
A harness makes failure visible and gives the agent a structured chance to recover. That doesn't guarantee correctness. It gives you a way to evaluate it.
The goal isn't an agent that confidently announces:
Everything is production ready! 🚀
It's a workflow that can prove:
✓ Architecture checks passed
✓ 6 behavior tests passed
✓ Changes reviewed before merging
→ Ready for human approvalWhat was the last thing your AI coding agent confidently broke? And more importantly: what single automated check would have caught it?
Tell me in the comments. I collect these stories the way some people collect Pokémon.
Further reading:
出处https://dev.to/holasoymalva/your-ai-coding-agent-doesnt-need-a-better-prompt-it-needs-a-harness-9ej
这条还缺什么证据?
下面每条都由本条已有字段推出(等级、理由、商业模式、来源次数、是否演示), 本站不生成推测性结论;通用验证方法放在方法论页。
- 可核验的收入或付费证据查官网定价页与付费口径;第三方数据源(如 GetLatka)只作旁证,需标注来源与时点。
- 商业模式未定确认按席位/按用量/授权还是开源托管版收费;开源项目另查 LICENSE 与是否存在付费版。
- 只有单一来源找一手站点或其他渠道是否重复出现同一产品;社区热帖数量不等于商业进展。
通用验证清单(谁有这个问题/谁愿意付费/一个人能交付哪一小步)见我们的筛选方法。