8.0
热点
AI SCORE
技术实践2026-08-16 12:45
程序员视角：快速识别AI生成的网站
dev.to · AI#AI编程#代码审计#工程实践
Editor brief · 编辑速览
总结了一套从UI、代码、架构、SEO和元数据识别「vibe coding」产物的具体检查点，并解释每个信号出现的原因，帮助程序员审计外包代码或评估竞品。
"凭感觉编程（Vibe Coding）"——通过提示词让 AI 生成代码、几乎不审查就接受产出——已从小众玩笑演变为主流工作流。Cursor、Bolt、Lovable、v0、Replit Agent 和 Claude Code 等工具让人们在一下午内交付一个能跑的网站，而无需手写多少代码。这确实很有用。但它也催生了一类特定且可识别的网站：构建速度快、功能往往正常，但充斥着暴露其构建方式的模式。
如果你是一位在审查代码库的技术负责人、一位在评估承包商工作的技术联合创始人，或者只是一个好奇为什么某个网站"感觉不对劲"的人，那么知道如何判断一个网站是否凭感觉编程是一项实用技能。本文将详细讲解在 UI、代码、架构、搜索引擎可见性和元数据中区分凭感觉编程网站与经过深思熟虑的工程实践构建的网站的具体技术信号，并解释每种信号出现的原因。
凭感觉编程是 2025 年流行的一个术语（据称由 Andrej Karpathy 推广），指的是一种开发风格：人用自然语言描述想要什么，AI 编码智能体生成实现，然后人运行输出、扫一眼结果、然后继续往下走，而不是逐行阅读代码。这个术语本身并无贬义；它描述的是一种工作流程，而非质量水准。但正因为这个工作流程跳过了传统的审查循环，某些类别的问题会持续漏过去。
这对于识别很重要：你不是在找"AI 写的"，因为 AI 辅助编程目前在大多数正经工程团队中已是标准做法。你在寻找的是：没有任何人对产出进行有意义的审查或理解就交付的迹象。程序员 Simon Willison 早期就划了同样的界限——将逐行审查、测试并理解每行生成代码的开发者，与纯粹把 AI 当作无人监督的作者来使用的人区分开来。
以下几种实际情况让这项技能值得掌握：
投资、收购或合作前的尽职调查 —— 评估初创公司的代码库。
招聘和合同验证 —— 确认自由职业者或代理商确实理解他们交付的内容。招聘人员越来越多地报告称，他们给候选人一些小编码测试，专门用来观察候选人是否能解释和维护自己的逻辑，而不仅仅是粘贴 AI 产出。
安全审查 —— 凭感觉编程的应用有一个有据可查的模式：暴露的 API 密钥、缺失的认证检查、未验证的输入。有些安全研究人员现在公开称其为"漏洞即服务"。
可维护性规划 —— 决定一个代码库是否可以安全扩展，还是需要重写。
营销和 SEO 规划 —— 一个网站可能看起来已完成，但在 Google、Bing 和 AI 答案引擎中仍然功能上不可见（详见下文）。
个人好奇心 —— 开发者喜欢弄清楚事物是如何构建的。
以上都不需要后端访问。下方大多数信号从浏览器、页面源代码或花几分钟使用浏览器开发者工具就能看到。
AI 页面生成器往往趋于收敛到相同的视觉词汇，因为它们在相似的组件库和设计模式上训练。注意观察：
以上单独任何一条都不是确凿证据。很多手工构建的网站也使用 Tailwind 默认的圆角，很多专业设计师也因为 shadcn/ui 本身的美学价值而喜欢它。问题在于组合和一致性——当一个网站的每个分区无一例外地遵循相同的卡片网格加图标模板、使用相同的配色方案，通常不是由逐个分区做决策的人类设计师设计的。
这往往是最强的单一信号，因为它根本不是一种风格选择——而是平台注入的基础设施，大多数人从未想过要移除它。
徽章。AI 构建器的免费套餐经常在自己的产出上盖章：角落里的"Edit with Lovable"标签、底部的"Made with Bolt"标记、"Built with v0"字样。徽章本身就是结论性的证据，尽管付费计划通常允许所有者移除它，所以它的缺失不能证明什么。
默认子域名。每个构建器都将新项目部署到自己的基础设施上。首先想到的是以 .lovable.app、.bolt.host、.replit.app/.repl.co 或 .base44.app 结尾的地址。一家企业在这些预览域名之一上运行其正式网站，说明他们不仅使用了 AI 工具，而且还没来得及离开沙箱。
注入的运行时脚本。查看页面源代码，寻找从构建器自己的 CDN 加载的平台管道代码，或者嵌入在 <head> 或 </body> 之前的看起来像内部的小脚本路径。这些在迁移到自定义域名后依然存在，因为所有者很少会深入原始 HTML 检查。
遗留的资产路径和元标签。有些构建器将每个上传的图片存储在独特的上传路径下，或者将自己的名字写入元标签（无论是自定义标签还是被劫持的 generator 标签）。所有者去除徽章的频率远高于重新托管每张图片，所以一个旧的上传路径是最持久的信号之一。
几乎为空的页面源代码。手工构建的业务网站通常是服务器端渲染的，页面源代码中充满了可读的文本。大多数 AI 构建器的默认输出是客户端渲染的单页应用，所以原始 HTML 几乎为空：一个 <div> 标签加几行 JS 加载标签。
有两件事值得特别点名，因为它们经常被当作错误的"陷阱"来反驳：使用 React、Vite 或 Supabase 本身不能说明任何问题——这些工具为大量经过仔细手工构建的软件提供支持，而通过 Wix、Squarespace、Webflow 或 Shopify 等无代码编辑器制作的网站则属于完全不同的类别，因为根本没有代码被生成。
上述每个指纹的问题在于，它只能单向生效。标记的存在是强有力的证据；但缺失不能证明任何东西。使用 Cursor、Claude Code 或 Windsurf 等 IDE 嵌入式助手编写的代码通过完全正常的仓库部署，根本不会留下任何构建器指纹，而且上述任何标记都可以通过后续的一个提示词手动删除。
这是最强烈、最容易识别的信号之一。在页面中搜索（Ctrl+F / Cmd+F）：
AI 脚手架工具生成完整的页面结构，包括看起来真实的填充内容，如果人不逐字逐句阅读输出就接受，这些填充内容就会留到生产环境。
点击所有东西。凭感觉编程的网站经常有：
#AI 生成的前端通常看起来精致，但通不过基本可访问性检查，因为视觉正确性很容易用眼睛验证，而可访问性需要刻意的测试：
图片缺失 alt 文本（查看页面源码或检查元素）。颜色对比度差，尤其是浅灰色文字配白色背景，这是 AI 生成内容常见的默认设置。用键盘 tab 键浏览页面时，看不到焦点状态。大量使用带有 onClick 处理程序的 div 和 span，而非语义化元素。
用 Lighthouse（内置于 Chrome 开发者工具）或 axe DevTools 运行页面，可以快速得到无障碍分数。如果一个视觉设计看起来很精致，但分数低于 70，这是一个有意义的信号——因为真正的无障碍工作需要人工测试，而纯"提示→接受"的工作流往往会跳过这一步。
这是一个容易被忽视的类别，因为网站可能看起来完全成型，但对搜索引擎来说却功能上不可见——这已经成为 AI 生成网站最常被报告的问题之一，恰恰因为从一眼扫过完全看不出任何端倪。
纯客户端渲染，没有可抓取内容。 大多数 AI 网站构建工具默认交付的是一个 JavaScript 密集型单页应用：服务器发送一个近乎空的 HTML 壳，浏览器随后通过运行脚本包来构建可见页面。搜索引擎爬虫首先抓取原始 HTML，如果 HTML 是空的，最初记录的就是空内容。完整渲染发生在之后，作为一个独立队列，有时是数天甚至数周之后——较小或较新的站点可能在第二次抓取发生之前就耗尽了抓取配额，导致网站大部分内容实际上未被收录。
重复或缺失的 meta 标签。 AI 生成的页面通常在每个页面上复用相同的标题和 meta 描述，或者通过复制页面第一句话来自动生成描述——搜索引擎会将这些视为低质量样板代码。
混乱的标题层级。 因为这些工具优化的是标题的视觉外观而非其语义含义，经常会看到多个
以上都不是说凭感觉编程的网站不能排名——一旦有人刻意修复了服务端渲染或预渲染、meta 标签、标题结构和结构化数据，它是能排上来的。但默认情况下，这些工具大多将 SEO 视为非目标，所以一个漂亮但完全没有有机搜索可见性的网站，是更可靠（虽然不那么显眼）的指标之一——表明没有任何人以搜索为导向来审视输出内容。
大多数检查并不需要仓库访问权限。右键 → 检查，或查看页面源码，就能走很远。
AI 编码助手往往生成比任务严格需要的更多代码，因为它们优化的是"产出正确输出"而非"最小化、符合惯用法"。在 React 或 Vue 网站中（如果你能查看打包后的源码，或者有仓库访问权限），注意寻找：
做几乎相同事情的多个组件，只是命名略有不同（Card.jsx、FeatureCard.jsx、ServiceCard.jsx 几乎都是重复的）。没有布局目的的深层嵌套 wrapper div——
人类维护的代码库往往会收敛到一种命名约定。AI 生成的代码，尤其是在多次提示会话或多个 AI 工具的情况下，通常不会：
// 同一文件，三种不同命名约定描述相似的东西
const user_data = fetchUserData();
const userProfile = getUserProfile();
const UserSettings = loadSettings();
你还会看到 camelCase 和 snake_case 混用、注释风格突变、同一个文件格式与单一 Prettier/ESLint 配置不一致——因为没有人真正做过全项目范围的格式化。
AI 生成的代码通常包含非常基础的注释解释代码在做什么，而非解释为什么做出某个决定——这与有经验的工程师写的代码完全相反：
// 遍历用户数组
for (let i = 0; i < users.length; i++) {
// 检查用户是否处于活跃状态
if (users[i].isActive) {
// 将用户添加到活跃用户数组
activeUsers.push(users[i]);
}
人类在审查并内化这段代码后，通常会删除这类注释，或者用解释非显而易见的业务规则的内容来替代。这类注释未被编辑修改、完整保留在已上线网站中，说明代码实际上从未被真正阅读过。
因为 AI 模型优化的是产出满足提示的代码，它们经常生成看起来正确但实际上没有任何作用的错误处理：
const response = await fetch('/api/checkout');
const data = await response.json();
console.log(error); // 然后就没有然后了
打开浏览器控制台，同时使用网站。凭感觉编程的网站经常抛出未捕获的错误、失败的 fetch 请求，或从未被处理的 React key 警告——因为在开发过程中没有人盯着控制台看。
如果你有更深层次的访问权限——GitHub 仓库、能探测的 API，或者能对构建者进行技术面试——这些信号比浏览器中可见的任何东西都更有力。它们也是迄今为止影响最大的一类：独立测试 AI 生成程序的研究反复发现，大约四成的程序存在可利用的缺陷，业界安全团队现在已将此视为预期基线，而非意外发现。
这是凭感觉编程最具影响力的失败模式，不仅仅是风格上的信号。检查页面源码和网络标签页，寻找：
AI 助手通常会精确按照要求行事——"添加 Stripe 结账"——以最直接的方式，这往往也是最不安全的方式，除非提示中明确指定了安全架构。这不是假设：密钥扫描研究追踪到每年有数千万个新密钥进入公开仓库，且逐年增长。已经发现，使用 AI 编码助手的仓库泄露 API 密钥、密码和令牌的概率明显高于不使用的仓库。有据可查的案例中，独立开发者因凭感觉编程的应用泄露了 API 密钥，被迫关闭项目重建，在攻击者耗尽其账户额度之后。
尝试向任何表单提交明显格式错误的输入：数量字段填负数、文本字段填 HTML 标签、超长字符串。凭感觉编程的后端在全面接受 AI 输出后，通常会跳过：
如果网站使用后端即服务（如 Supabase 或 Firebase，这在 AI 辅助技术栈中很常见，因为搭建速度快），有时可以检查：
Supabase 本身现在发布的指南中指出，这类漏洞在 AI 脚手架后端中足够常见，敦促构建者在称应用为生产就绪之前，明确验证行级安全策略并测试账户之间的数据隔离，而非假设安全默认值。
Dependency and Supply Chain Red Flags This is a newer, less obvious category, but it's become common enough that security vendors track it as a distinct risk. AI coding assistants sometimes recommend software packages with complete confidence including ones that don't actually exist. Researchers studying this "package hallucination" problem found a meaningful share of AI-suggested dependencies referenced packages that were never published, and that the same invented names tend to reappear consistently across repeated runs of the same prompt. That predictability matters, because it lets attackers register the invented package name in advance and wait for someone to install it, a technique researchers call "slopsquatting."
依赖与供应链警示信号这是一个较新、不太明显的类别，但它已经变得足够普遍，安全厂商将其作为独立风险进行跟踪。AI 编程助手有时会自信满满地推荐软件包——包括那些根本不存在的包。研究人员对这一"软件包幻觉"问题进行研究后发现，AI 建议的依赖中有相当一部分引用的是从未发布过的软件包，而且相同的虚构名称在反复运行相同提示时往往会一致地重复出现。这种可预测性很重要，因为它让攻击者能够提前注册这个虚构的软件包名称，然后等待有人安装它——研究人员将这种技术称为"slopsquatting"（垃圾包抢注）。
What to check if you have repository access:
如果你有代码仓库的访问权限，需要检查以下内容：
Whether package.json (or the equivalent manifest) lists an unusually large number of dependencies for how simple the app appears, AI assistants tend to reach for a new library per feature rather than reusing what's already installed. Whether a lockfile is committed, which pins exact dependency versions and protects against a compromised upstream package silently changing what gets installed. Whether any listed package looks unfamiliar or has an implausibly small download count for something this project supposedly depends on.
Repository History (If Accessible) If you have access to the Git history, this is often the single clearest signal:
代码仓库历史（如果有访问权限）如果你能访问 Git 历史，这往往是最清晰的单一信号：
A commit history of huge, single commits ("Initial commit," "added stuff," "fix") rather than incremental, described changes. No .gitignore covering .env files, log output, or other machine-generated artifacts meaning secrets and clutter have a real chance of having been committed at some point in the project's history, even if removed later. No tests directory, or a tests directory added once and never touched again. No CI/CD configuration, no linting config, no pre-commit hooks, and no evidence of separate development/staging/production branches. A package.json with an unusually large number of dependencies for the app's apparent complexity, echoing the supply-chain concern above.
Vibe Coding Signals: Quick Reference Table
凭感觉编程信号速查表
| Signal | Category | What to Check | Strong Indicator |
|---|---|---|---|
| Visual design | Repetition of card/icon layout, generic gradients, emoji, glow effects | Every section uses the identical template and palette | |
| Builder fingerprints | Corner badges, default subdomains, injected scripts, leftover upload paths | Any platform-specific marker found in source | |
| Page content | Search for "lorem ipsum," placeholder names | Any placeholder text found | |
| Interactivity | Click buttons and submit forms | Dead links, silent form failures | |
| Accessibility | Run Lighthouse/axe | Score below ~70 with polished visuals | |
| SEO / indexing | View source for content, check Search Console, count H1 tags | Empty HTML shell, duplicate meta tags, multiple H1s | |
| Source code | View source, inspect elements | Deep div nesting, mixed naming conventions, HTML comments like <!-- Hero --> |
|
| Console | Open browser dev tools console | Uncaught errors, failed requests | |
| Network tab | Check API calls | Client-side calls with exposed keys | |
| Forms | Submit invalid data | No server-side validation | |
| Repo (if available) | Commit history, package.json, lockfile | Single huge commits, no tests, no CI, no lockfile |
| 信号 | 类别 | 检查什么 | 强烈信号 |
|---|---|---|---|
| 视觉设计 | 卡片/图标布局重复、通用渐变、emoji、光效 | 每个版块都使用相同的模板和配色 | |
| 构建者痕迹 | 角落徽章、默认子域名、注入的脚本、残留的上传路径 | 在源代码中发现任何平台特定标记 | |
| 页面内容 | 搜索 "lorem ipsum"、占位符名称 | 发现任何占位符文本 | |
| 交互性 | 点击按钮并提交表单 | 死链、表单静默失败 | |
| 可访问性 | 运行 Lighthouse/axe | 视觉精致但分数低于约 70 | |
| SEO / 索引 | 查看源代码内容、检查 Search Console、统计 H1 标签 | 空 HTML 壳、重复的 meta 标签、多个 H1 | |
| 源代码 | 查看源码、检查元素 | 深层 div 嵌套、混合的命名规范、类似 <!-- Hero --> 的 HTML 注释 |
|
| 控制台 | 打开浏览器 dev tools 控制台 | 未捕获的错误、失败的请求 | |
| Network 标签页 | 检查 API 调用 | 暴露密钥的客户端调用 | |
| 表单 | 提交无效数据 | 无服务端验证 | |
| 仓库（如果有） | 提交历史、package.json、lockfile | 单一的巨型提交、无测试、无 CI、无 lockfile |
Traditional Development vs. AI-Assisted (Vibe-Coded) Development
传统开发 vs AI 辅助开发（凭感觉编程）
| Aspect | Traditional / Reviewed Workflow | Pure Vibe-Coded Workflow |
|---|---|---|
| Code review | Every change reviewed by a human or peer | Output accepted if it "looks right" |
| Testing | Unit/integration tests written alongside features | Often skipped entirely |
| Error handling | Deliberate, specific to failure modes | Generic try/catch, often silent |
| Security | Reviewed against known threat models | Frequently overlooked until exploited |
| Dependencies | Vetted, pinned with a lockfile | Added freely per feature, sometimes hallucinated |
| SEO | Planned as part of the build | Rarely considered by default tooling |
| Naming/style | Enforced via linting and convention | Drifts across prompting sessions |
| Comments | Explain "why," sparse | Explain "what," verbose and generic |
| Architecture | Planned before implementation | Emerges from incremental prompts |
| 维度 | 传统/审查工作流 | 纯凭感觉编程工作流 |
|---|---|---|
| 代码审查 | 每个变更都由人或同行审查 | 如果"看起来对"就接受输出 |
| 测试 | 与功能同时编写单元/集成测试 | 通常完全跳过 |
| 错误处理 | 有意为之，特定于失败模式 | 通用的 try/catch，通常静默 |
| 安全 | 根据已知威胁模型审查 | 常被忽视直到被利用 |
| 依赖 | 经过审核，用 lockfile 锁定 | 每个功能自由添加，有时是幻觉的 |
| SEO | 作为构建的一部分规划 | 默认工具很少考虑 |
| 命名/风格 | 通过 linting 和规范强制执行 | 在提示会话中漂移 |
| 注释 | 解释"为什么"，简洁 | 解释"是什么"，冗长且通用 |
| 架构 | 在实现前规划 | 从增量提示中涌现 |
This isn't a claim that AI-assisted code is inherently worse; plenty of teams use AI coding agents with rigorous review, testing, and security practices, and that code is indistinguishable from traditionally written code by most of these signals. The table describes the difference between reviewed and unreviewed output, not between human-written and AI-written code.
这并不是在说 AI 辅助编写的代码本质上更差；很多团队使用 AI 编程智能体时配合严格的审查、测试和安全实践，他们的代码用大多数这些信号来衡量与传统编写的代码无法区分。这个表格描述的是经过审查和未经审查的输出之间的区别，而不是人类编写和 AI 编写的代码之间的区别。
How to Spot a "Vibe Coder" in an Interview or Code Test
如何在面试或代码测试中识别"凭感觉编程者"
Detecting vibe-coded output isn't only about auditing finished websites hiring managers and technical co-founders increasingly need to evaluate whether a candidate or contractor actually understands the code they're submitting. A few practical approaches that experienced interviewers report using:
检测凭感觉编程的输出不仅仅是为了审计已完成的网站——招聘经理和技术联合创始人越来越需要评估候选人或承包商是否真正理解他们提交的代码。以下是经验丰富的面试官报告使用的几种实用方法：
Ask them to explain a specific decision, not just describe the feature. Someone who understands their own code can walk through why a particular approach was chosen and what the trade-offs were. Someone who only accepts AI output tends to describe what the code does at a surface level and struggles once you ask "why this way and not another way."
让他们解释一个具体的决策，而不仅仅是描述功能。理解自己代码的人能够讲解为什么选择某种方法以及权衡是什么。只接受 AI 输出的人往往只能肤浅地描述代码做什么，一旦你问"为什么这样做而不是另一种方式"就会卡住。
Watch how they debug. Ask a candidate to fix a deliberately broken piece of code live. A developer who understands the codebase breaks the problem down and reasons through it; someone leaning entirely on AI often pastes the whole error into a chat tool and waits for a suggestion without evaluating whether it's actually the right fix.
观察他们如何调试。让候选人在现场修复一段故意破坏的代码。理解代码库的开发者会将问题分解并推理；而完全依赖 AI 的人往往会将整个错误粘贴到聊天工具中，等待建议而不评估它是否真的是正确的修复。
Look for a coherent problem-solving process, not just a working answer. Working code isn't proof of understanding on its own plenty of vibe-coded submissions technically run. The signal is whether the person can iterate on their own reasoning when you change the requirements slightly.
寻找一个连贯的问题解决过程，而不仅仅是一个能工作的答案。能运行的代码本身并不能证明理解——很多凭感觉编程的提交在技术上也是能运行的。真正的信号是当你要稍微改变需求时，这个人是否能够迭代自己的推理。
Small tells matter, but treat them as one clue among several. Leftover AI-style comments, inconsistent naming, or emoji sprinkled through variable names or commit messages in a take-home test can be worth a follow-up question rather than an automatic red flag plenty of legitimate AI-assisted work has small tells like this, and the point is to ask, not assume.
小细节很重要，但要把它当作多个线索中的一个来对待。在回家作业测试中，残留的 AI 风格注释、不一致的命名，或者在变量名或提交信息中散布的 emoji，值得作为一个后续问题而不是自动的红牌警告——很多合法的 AI 辅助工作都有这样的小细节，重点是提问，而不是假设。
Tools You Can Use to Investigate
你可以用来进行调查的工具
Browser DevTools (built into Chrome, Firefox, Edge) inspect elements, check the console for errors, view the network tab for exposed API calls.
浏览器 DevTools（内置于 Chrome、Firefox、Edge）——检查元素、检查控制台错误、查看 network 标签页中暴露的 API 调用。
Lighthouse (Chrome DevTools → Lighthouse tab) scores performance, accessibility, best practices, and SEO in one report.
Lighthouse（Chrome DevTools → Lighthouse 标签页）——在一份报告中对性能、可访问性、最佳实践和 SEO 进行评分。
axe DevTools (browser extension) deeper accessibility auditing than Lighthouse alone.
axe DevTools（浏览器扩展）——比单独使用 Lighthouse 更深入的可访问性审计。
Google Search Console the clearest way to check whether a site's pages are actually indexed, and to see which pages Google has crawl errors for. BuiltWith (builtwith.com) tells you what frameworks and services a site is built with. Censys (censys.io) or similar internet scanning tools can identify the hosting provider, SSL cert details, and server software versions for a given domain. VirusTotal (virustotal.com) or similar URL scanners let you check whether a domain or URL is flagged as malicious by any security vendors.
Google Search Console——检查站点页面是否真正被索引、以及 Google 对哪些页面有爬取错误的最清晰方式。BuiltWith（builtwith.com）——告诉你一个站点是用什么框架和服务构建的。Censys（censys.io）或类似的互联网扫描工具可以识别给定域名的托管提供商、SSL 证书详情和服务器软件版本。VirusTotal（virustotal.com）或类似的 URL 扫描器让你检查域名或 URL 是否被任何安全厂商标记为恶意。
Wappalyzer (browser extension or wappalyzer.com) similar to BuiltWith, identifies the tech stack including frameworks, analytics tools, and server-side languages.
Wappalyzer（浏览器扩展或 wappalyzer.com）——与 BuiltWith 类似，识别技术栈，包括框架、分析工具和服务器端语言。
GitHub's dependency graph (available on public repos) shows you what packages a project depends on and whether any have known vulnerabilities.
GitHub 的依赖图（公开仓库可用）——显示项目依赖哪些软件包以及是否有任何已知漏洞。
The point isn't to run every tool on every site. Pick one or two based on what you're trying to find out. If you're a developer evaluating a take-home test, the source code inspection and the Lighthouse accessibility report will tell you most of what you need to know. If you're a security researcher evaluating a third-party script or an unknown site, builtwith and VirusTotal give you a fast external picture before you even open the browser.
重点不是对每个站点都运行每个工具。根据你要查找的内容选择一两个。如果你是评估回家作业测试的开发者，源代码检查和 Lighthouse 可访问性报告会告诉你大部分你需要知道的信息。如果你是评估第三方脚本或未知站点的安全研究员，builtwith 和 VirusTotal 在你打开浏览器之前就给你一个快速的外部图景。
Conclusion Vibe coding isn't going away. As AI coding tools improve, the outputs will become harder to distinguish from human-written code, and the signals described here will become less reliable. That's worth keeping in mind: the goal of this checklist isn't to create a permanent taxonomy of what AI-assisted output looks like, but to document what the current generation of AI-assisted output looks like right now, when review hasn't been part of the process.
结论凭感觉编程不会消失。随着 AI 编程工具的改进，其输出将越来越难以与人类编写的代码区分开来，这里描述的信号也将变得不那么可靠。值得记住的是：这份检查清单的目的不是创建一个关于 AI 辅助输出长什么样的永久分类法，而是记录当前这一代 AI 辅助输出在审查尚未成为流程一部分时的现状。
The signals that survive into the future will be the human ones: the ability to explain decisions, the presence of a coherent development process, and the kind of contextual judgment that no tool can generate for you. Those aren't things you can detect from a source code inspection or a Lighthouse score. But they're exactly the things that separate someone who uses AI as a power tool from someone who uses it as a crutch.
在未来仍然有效的信号将是那些属于人类的：解释决策的能力、存在连贯的开发过程，以及没有任何工具能为你生成的上下文判断能力。这些都不是你能从源代码检查或 Lighthouse 评分中检测到的。但它们恰恰是将使用 AI 作为动力工具的人与使用 AI 作为拐杖的人区分开来的东西。
If you're hiring or evaluating code, the most reliable signal isn't in the code at all. It's in the conversation.
如果你在招聘或评估代码，最可靠的信号根本不在代码里。它在对话中。