夜雨聆风零基础一个月：我的第一个AI辅助阅读插件诞生记
为什么做这个产品
市场上现有的AI阅读工具大多是多功能集合包，年费动辄数百元，实际体验却参差不齐。作为一个正在学习AI技术的iOS开发者，我决定自己动手，用vibe coding的方式做一款轻量级的浏览器插件——ReadCue。
这款插件提供三个核心功能：文章摘要、阅读大纲、批判性评价。用户可以免费使用，只需配置自己的API key。
从构思到提交审核，前后历时一个月。对我而言，这是完全陌生的前端领域，却也是第一次真正体验AI如何重塑软件开发方式。
开发工具链
选型过程
产品需求确认阶段，我对比了Claude Opus、GPT 5.5和Kimi 2.6。GLM因为入门会员经常缺货被排除。最终Claude的综合表现最稳定，因此购买了20美元/月的入门会员，与一直订阅的Plus会员组合使用。
主力开发工具为Claude Code，偶尔配合Codex。
IDE选择
Cursor作为日常编辑器，主要用于三个场景：
文档管理
产品背景文档、技术方案讨论统一存放在docs目录下，在IDE内直接修改。代码Review
功能完成后检查diff，涉及面较广时会更新CLAUDE.md，文件过长或职责混乱时进入重构流程。警告修复
IDE警告附带行号定位，在插件中选中代码直接对话处理。插件内配置中等模型即可。
VS Code或国产Trae同样可用，差异不大，看个人习惯。
原型设计的新范式
HTML的文艺复兴
没想到互联网诞生之初的HTML协议，在AI时代迎来了第二春。
它的本质已经改变：现在它是基于文本的跨平台可交互内容载体。由于开源网页代码库庞大，AI生成质量相当高。HTML顺理成章成为生成可交互原型的首选，甚至出现了基于网页生成视频的方案。
用可交互网页做原型设计，堪称一次范式革命。
过去的原型只能用静态线框图展示，数据流动和交互逻辑很难体现。虽然可以在图上标注点击区域和跳转路径，但距离完整表达产品意图仍有差距。设计图同样是静态的，产品经理、设计师、研发三方使用完全不同的数据语言，从原型到设计、从设计到开发，中间存在"物种级"隔阂。
网页打破了这一切。高保真的、具备完整交互的网页成为新的需求载体。产品经理和设计师在同一份网页上验证流程，这份文档交给开发时已经高度可用。Agent可以直接基于这份高完成度的需求文档开始编码——当然技术选型仍需人工决策，但对产品需求和设计样式已有充分说明。
Claude Design体验
本次产品的原型和设计全部在Claude Design中完成。
新项目可选择设计系统后调整，现有项目可从已有项目生成或手动导入。
设定设计系统后，描述需求即可生成网页。生成结果可在edit模式下点选编辑属性，选中元素后标注修改意见发送给模型，实现"指哪打哪"的效果。
交付方式有两种：通过MCP分享给Claude Code，或导出HTML包。前期交流可发送链接在互联网端查看。
由于这是前端项目，Claude Design中的效果可以实现100%还原。独立完成整个设计-开发闭环时，震惊之余甚至想象自己就是Sam Altman瘫坐在椅子上。
没有Claude会员的话，Open Design是不错的替代方案——本身免费，迭代速度可观。
需要注意的是，设计类Agent需要全量读写网页，token消耗很快。参考他人建议使用Opus后，20美元的Pro套餐完全不够，最终只能升级Max。
Figma的局限
四月曾尝试通过MCP连接Figma直接在项目中生成UI，实际效果不理想：ScrollView、Grid等组件输出经常偏离预期，阴影、渐变等设计细节还原度也不足。
问题根源在于两点：
静态设计图信息量有限
横向滚动区域是否支持、光靠设计图很难判断；Grid布局稍有复杂，AI理解偏差在所难免——同样的图，人类开发者有时也会理解错误。设计文件非原生HTML
AI在读取和转换Figma内容时，必然存在理解偏差。
设计工具与 AI 的适配困境
我曾尝试将 Whimsical（原型设计工具）接入 Claude，通过 MCP 直接将 PRD 转换为线框图，但实际效果并不理想。问题在于这类设计平台普遍存在私有 DSL 和自定义元素体系，AI 在生成 UI 之前需要先"学习"这套方言，翻译过程中的信息损耗不可避免。
相比之下，以 HTML 作为数据层的方案目前表现更优。这让我对富媒体数据层的技术路径抱有信心——结构化的标记语言天然具备跨平台翻译的适配优势。
传统手写代码的时代已经过去了
AI 编程能力的发展速度已经超越了大多数人的预期。最初只是函数级别的自动补全，后来 Sonnet 4.0 实现了单文件级代码生成，而跨文件的完整功能模块长期令人担忧。直到 Opus 4.5 出现，配合 Plan mode 指定开发计划，已经能产出完整度极高的代码——这才让我真正确信：手写代码的时代已经过去了。
促使代码生成跨越可用性门槛的，是多个维度的同步进步：大参数模型、更长上下文窗口、Coding Agent 工具链的成熟，加上 LLM 天然吸收了大量优质代码。在 Scaling Law 驱动下的增长曲线，远比半导体行业的摩尔定律更为陡峭。
真正令人震撼的并非 AI 具备替代能力本身，而是渗透的速度。Claude Code 与 Sonnet 3.7 于 2025 年 2 月发布，短短一年内就完成了一个行业的颠覆。参照历史：电力从城市应用到全面普及耗时约十年；即便距离更近的移动互联网，从 3G 商用牌照发放到 4G 普及也走过了五年。一项延续数十年的高薪白领技能，在十二个月内急剧贬值。
这次变革的性质更接近印刷术的发明。掌握文字书写曾是高级技能，但众多"文字工作者"的日常不过是机械抄写经书。印刷术普及后，抄写员便退出了历史舞台。
这并不意味着程序员职业将消亡，而是编程进入了更高的抽象层次——用自然语言构建功能。不过软件工程的体系依然必要，只是生产关系需要重新适应新的生产力。
开发流程的重构
需要明确一个前提：能运行的代码与能被维护的代码是两回事。项目全程无需手写代码，并不意味着不需要阅读和审核代码。验收标准是：在提供清晰上下文与目标的前提下，AI 生成的代码具备可维护性。
这与一次性 Demo 项目的标准截然不同。Demo 的代码可以不管，是因为交付验证后原始代码不再改动。而真实项目持续迭代，每一轮都在既有基础上构建，代码质量直接影响后续的扩展成本。一旦可维护性不足，迭代积累的技术债务最终会导致系统混乱、bug 频发。
以下是我实践出的三步开发流程：
第一步：需求讨论，输出初始 PRD。 撰写粗糙的需求文档，交代背景与目标后导入 Claude Code，进行一轮需求可行性讨论。此阶段明确要求 AI 聚焦需求的合理性，而非实现细节。确认大方向后让 AI 输出一版正式 PRD。这个过程还可能发现某些功能实现过于复杂，从而决定暂缓或放弃。
第二步：Claude Design 确认需求设计。 将初始 PRD 投入 Claude Design，输出设计稿。中小型项目可直接生成高保真设计，大型项目则可先输出线框图。在交互过程中，往往会发现诸多设计与最初的想象存在偏差——最初只考虑功能需求，对具体交互方式、现有产品中的接入位置、数据流向都很模糊。生成可交互的设计稿后，便能验证功能是否符合预期、细节是否满意。设计确认后导出 HTML，必要时同步更新原始 PRD。
补充：原型探索技巧。 来自 Matt Pocock 的一个实用技能——用于探索实现路径，生成的是可抛弃代码。在项目中快速搭建几个草稿方案，对比效果后辅助决策。例如布局方案可以让 prototype 同时生成几个版本供选择，直观对比优劣。
第三步：制定开发计划。 使用 mattpocock-skills/grill-with-docs 技能，将 PRD 与设计文档导入 Claude Code。该技能的核心机制是让 AI 反向提问——从实现角度发起多轮追问，涵盖技术方案到交互细节。这个"被拷问"的过程能加深对功能实现路径的理解。技能同时会自动记录架构决策与 Context。当所有实现路径确认完毕后，调用 to-spec 技能生成开发计划。对于较大的功能模块，可继续调用 to-tickets，将计划拆解为具体子任务，并同步至 GitHub Issues 或本地管理。
实现阶段
拿到 spec 文档后，结合前期的 PRD 和设计稿，开发工作完全可以交给其他 coding agent 完成。关于模型选择，有人建议用中等性能模型完成实现，这个建议是合理的。但更关键的一点是：规划阶段必须使用高思考密度的模型（如 Opus、GPT Sol）。前期的探索和规划决定了后续实现的质量上限，模型的思维广度和深度直接影响最终效果。
进入实现环节，我会在不同模型间切换。Sonnet 5 适合开启新的会话，Codex 则在需求明确时的编码稳定性表现优异。
实现过程中存在两条路径：使用内置的 Plan 模式，或调用 Matt 中的 implement 技能。implement 技能本质上没有太多玄机，只是强调 TDD 原则。Plan 模式的优势在于能预览具体的接口设计和方法实现。如果某个 ticket 需要关注实现细节，我会选择 Plan 模式；否则直接执行 implement。
架构检查与重构
核心功能完成后，需要审视架构是否需要调整。我有两处可以进行检查：一是 Plan 模式下查看开发计划，观察类如何组织、接口如何定义；二是功能实现后审查核心文件的 diff，判断实现是否足够优雅。两处至少选其一进行检查。
如果在规划阶段已审视过架构，实现时可能就不需要再看具体代码；如果前期是整体推进的，则在提交前必须过一遍改动。
判断是否需要重构，主要关注三个维度：文件行数是否过大（超过 500 行需重点关注）、是否复用了已有的组件或 hook、某个功能的实现是否涉及过多文件的修改。这些判断标准与以往手写代码时并无不同——代码中的"坏味道"依然需要被察觉。
与以往不同的是，重构的执行变得轻松许多。调用 improve-codebase-architecture 技能，将可疑文件或具体问题直接告知 AI，它会生成一份重构建议报告，你只需从中选择合适的方案即可。
在清晰的需求文档、设计稿和开发计划的支撑下，AI 已经能够独立完成高质量的功能实现。Plan 模式审视开发计划、完成后 review 核心 diff，这两个环节让我对代码始终保持掌控。虽然没有手写一行代码，但项目的工程质量、可维护性和可扩展性，依然有保障——不需要手写代码，不代表不需要关注代码。
新的价值锚点
我们正处在一个工具能力不断外包，但判断责任重新回到个体身上的时代。AI 可以极大地放大执行效率，却无法替你决定目标；可以降低行动门槛，却无法替你承担选择后果。工具越强，方向就越重要。 ——《AI 时代的认知觉醒》
AI 在代码生成环节的能力已经足以替代传统程序员的大部分工作。在 AI 辅助下，开发者的角色转变为如何驾驭 AI 产出期望的代码。程序员在写代码这件事上已经没有优势，但在代码到高质量软件交付之间，依然需要人类的参与。
这种参与分为两个层面。
代码层面：关注软件架构。 确保代码的健壮性和可维护性。当下 AI 的上下文窗口仍然有限，无法将注意力投射到整个代码库。因此 AI 生成的代码往往是局部最优解，从全局视角审视可能存在隐患——比如忽视复用逻辑、在现有架构上打补丁。架构优化这部分也许未来也会被逐步替代，毕竟本质上还是在写代码。但在此刻，人的参与依然必要，根本原因在于代码需要责任人。谁来确认生成的代码是合格的？AI 代码中 99.9% 是正确的，万一那 0.1% 的错误引发核心 bug 呢？
产品层面：参与技术决策。 AI 在写代码时无法获知完整的产品上下文，不参与产品定义。同样一个功能，正确的实现路径可以有多条，需要有人决定选择哪一条。这个决策既涉及产品规划，也涉及团队协作，很多因素无法在开始时完整传达给 AI。举例来说，保存用户属性应该存在本地还是服务端？项目是面向公司内部还是百万级用户？这些技术决策都与产品紧密相关，需要人的判断介入。
用一个比喻：假设你拥有能做任何菜品的厨师机器人，但你开饭馆时，不可能做全世界的菜。产品定位决定了菜单——是走量的快餐，还是精品的私厨。
程序员从代码实现的具体工作中跳出来，转而关注技术决策和产品决策。这本质上是一次稀缺性的迁移：当"如何实现"变成随手可得的资源，真正有价值的变成了"做什么"和"为谁做"。厨师机器人能做出世上所有菜品，但决定这家店走量还是走精品的，永远是开店的人。
编程并未消失，而是被推到了更高的抽象层级——从"如何实现一个功能"，演变为"这个功能该不该存在、边界如何划定"。程序员的角色从给出答案的人，变成了定义问题的人。
不要迷信大模型：骨子里的不确定性
新用户最容易犯的错误，是对 AI 过度信任。看到顶级模型能解决复杂数学问题、输出高质量的深度研究，很容易将其视为万无一失的智能伙伴。加上 AI 自媒体铺天盖地的"零基础几天做出酷炫产品"的宣传，期望值会被进一步拉高。然而真正开始做严肃项目时，就会发现大模型的可靠性远没有宣传的那么美好。
以下几个因素共同造成了这种不靠谱：
先天的局限：知识广而不精 + 概率式生成
大模型的“智能”究竟是怎么回事
要理解 AI 编程工具为什么时而可靠、时而翻车，先得搞清楚大语言模型的工作原理。
续写机制与“智能”
生成式 AI 的本质是通过海量语言数据的学习，掌握预测下一个词元的能力。换句话说，它在做的事是“续写”——给定一个不完整的句子，预测接下来该出现什么内容。
这之所以能产生某种程度的“智能”，是因为语言的表达本身具有逻辑连贯性。模型在学习大量续写任务的过程中，自然而然掌握了一定的推理能力。
举一个经典的例子：
如果明天下雨，小明就会带伞。明天下雨了，所以小明。
模型如果能正确续写出“会带伞”，说明它确实在通过某种逻辑链条得出结论，而非简单匹配模式。
知识记忆≠推理能力
不过，模型也会存储大量知识储备。比如“中国的首都是”后面最常出现的词元是“北京”，模型就记住了这个搭配。这种记忆行为类似背诵九九乘法表——记住的是事实本身，而非推导过程。
推理能力和知识储备是两回事。一个擅长复杂推理的模型，未必比另一个更能背诵百科知识。
“摇骰子”机制与输出多样性
每次续写时，模型面对的并非唯一答案，而是一组带有概率权重的选项。模型会根据温度参数（softamx）筛选其中一个选项，并非总是选择概率最高的那一个。
以填空题为例：“形容时间过得很快的成语是__”可能存在多个正确答案。如果模型总是输出最高概率的选项，回复就会趋于同质化。
再举一个更直观的例子：假设大模型学习语料时发现，喜欢咸粽和甜粽的人群各占一半。面对“粽子是甜的还是咸的好吃”这个问题，固定回答其中一种反而显得不客观。因此模型会在两种答案之间随机切换——因为生成内容本质上是一场“摇骰子”，相同的提示词每次可能产生不同的回复。
可靠性依赖三个条件
大模型要给出正确答案，需要同时满足：
- 训练语料中包含正确内容——模型没有学习过的知识自然无法调用
- 学习后的参数函数反映正确的逻辑——即使知道正确答案，也可能因为推理链条出错而输出错误结论
- 生成时“摇”到了正确的路径——随机性本身就是一个不稳定因素
这三个条件缺一不可，任意一个出问题都可能导致答案偏离预期。
为什么不该盲目信任
搞清楚这些底层机制后，我们应该对大模型的输出多一分审慎、少一分盲从。
面对综合性强的问题，模型不能保证每次都答对。你无法确定它学到的“解题方法”是否真正适用于你的问题，也无法预测这次生成是否恰好选中了正确路径。最终的验证工作，终究要由人来完成。
关键认知： 大模型的智能与人类智能本质上是两种不同的智能架构。它可能在某些领域远超人类水平，却也可能在另一些看似简单的问题上翻车——比如“strawberry里有几个r”，或者“去50米外的洗车店要不要开车”。
这种“看似全能、实则偶尔掉链子”的现象，并非模型缺陷，而是两种不同智能机制运作方式的必然结果。
上下文长度：大模型的另一道坎
大模型的输出质量还受一个关键因素制约——上下文长度。
注意力计算的代价
这里的上下文，指的是输入中用于续写的前置内容，包括用户提供的提示词。当模型处理这些上下文时，需要让每个字与所有其他字建立注意力连接。
原始 Transformer 架构中，注意力矩阵的计算复杂度是 O(n²)。假设输入长度从 100 增加到 200，表面上看只多了一倍内容，但实际计算量从 10,000（100²）暴增到 40,000（200²），增长了整整 3 倍。
由于计算成本随上下文长度呈平方级增长，现有大模型要支持百万级上下文，几乎都依赖注意力优化或压缩技术：
- DeepSeek 采用 MLA（多头潜在注意力）
- Kimi 发布 KDA（Kimi Delta Attention），可将 KV Cache 压缩最多 75%
注意力丢失：越长越容易健忘
上下文越长，模型“记不住”内容的概率就越高。这引出了一个经典问题：lost in the middle——模型倾向于遗忘中间部分的信息，对开头和结尾的注意力反而更强。
在代码开发场景中，这个问题尤其突出。很多综合性任务需要查阅大量代码文件，引入大量上下文，这就埋下了两个隐患：
上下文容量有限——某个完美方案可能需要关联 5 个代码文件，但模型实际只检索到 4 个，最终输出的方案因此打了折扣
注意力丢失——一个任务交代了 5 点要求，结果因为上下文过长或注意力压缩机制，模型漏掉了其中 1 点，导致功能缺失或实现偏差
更棘手的是，这种失败完全随机。你很难预测在哪个场景下，模型会突然“智力下线”。
应对策略
症状较轻时，可以在会话中补充提示。严重时常见的处理方式包括：
- 执行 compact 指令，让模型重新阅读并压缩上下文
- 找到模型仍“清醒”的那轮对话，fork 出新会话继续
- 执行类似 handoff 指令，将当前会话总结为文档，新开会话导入后继续
有观点认为，上下文长度并非全部可用，只有前 20% 的区间属于“聪明区间”，超过这个阈值模型能力会急剧下降。不过具体阈值因模型而异：Claude Code 配置到 400k 时会自动触发压缩，而 Codex 的上下文窗口更小，会更积极地进行压缩处理。
总之：解决复杂问题时，需要警惕上下文长度带来的不确定性。这是一个需要主动管理的风险因素。
Coding Agent 本身的 Bug
只要是软件，就不可能没有 bug。AI 编程工具也不例外。
持续使用这类工具，偶尔遇到意料之外的问题是常态。有的 bug 厂商会公开说明，有的可能悄悄修复就翻篇了，用户端只能感受到某些时段模型似乎突然“降智”。
一个典型的翻车场景
以 Claude Code 为例，曾遇到客户端突然无法正常使用基础工具的情况：修改文件时，工具调用显示成功，回复也声称完成了操作，但实际上文件根本没有被修改。如果不逐一核对每个关键操作的结果，错误就会持续累积。
还有一种情况更加诡异：模型突然表现得像“中了毒”，原本连贯的逻辑瞬间退化为小学生的思维水平。
这类问题提醒我们：工具的能力不等于工具的稳定性。在使用 AI 编程辅助时，保持对输出结果的主动验证，仍然是必要的基本功。
另一个令人困扰的情况是：当需求明确只是几行代码的改动时，模型却陷入了漫长的思考过程。
核心提醒：别假设 AI 不会出错
三个因素叠加决定了 AI 出错是必然的——大模型的概率性语言生成机制、上下文注意力的局限性，以及软件本身的稳定性。这意味着人的价值在于：不是将任务完全托付给 AI，而是通过协作放大工具能力，最终交付高质量成果。
主流模型的 Coding 表现（截至 26.07）
⚠️ 各模型迭代迅速，以下仅为当前阶段的个人体验，观点会快速过期。
规划阶段：Claude 是首选
Claude 的思维活跃度明显更高，人机交互体验更流畅。在审美和写作方面，Claude 的表现也比 GPT 均衡。结合 100 万上下文和 Claude Code，在规划阶段几乎没有对手。
不过 Claude 也有短板：工程稳定性不及 GPT，也不具备图像生成能力。使用 Opus 时，偶尔会遇到单个任务执行时间过长的问题，而 Codex 的执行时长更符合预期。
执行阶段：GPT 指令遵循更可靠
GPT 的指令遵循能力是最大的亮点。无论是注意力算法的独家设计，还是后训练的专项强化，在实际使用中从未出过差错。
相比之下，Claude 和 DeepSeek V4 都偶有失误。大约在 GPT 5.4 时期，在边界明确的编程任务上，Codex 的表现已经优于 Claude。GPT 5.6 Sol 的对话体验也正常了许多，综合能力提升明显。
GPT 的主要限制：普通会员的 Codex 上下文窗口不支持 100 万，只有 API 才具备，且费用更高。
组合策略
规划用 Claude，执行用 GPT，可能是当前的最优组合。
国内模型：Kimi 与 GLM 并驾齐驱
K3 的惊艳表现让国产模型正式进入第一梯队。Kimi 在技术架构上暂时领先——K3 接近 3T 的参数量、原生多模态能力都优于 GLM。不过目前 K3 仅提供 Max 档位，缺少中档和快速版本。受限于资源，顶级模型的综合能力仍有差距，但在部分场景下已能正面交锋，且价格更具优势。
DeepSeek V4 Pro：性价比选手
V4 Pro（预览版）的思考质量约为 Sonnet 5 和 GPT 5.6 Terra 的八九成，差距不大。在同价位上，DeepSeek 的性能表现确实突出。但面对较高复杂度的编程场景时，如果仅依赖 DeepSeek，可能因思考深度不足导致返工，综合性价比反而未必最优。
这也解释了「葬 AI 综合性价比榜」上，DeepSeek V4 Pro 排名低于 GLM 5.2 和 K3 的原因。
Claude 订阅的实操经验
我的方案是美区 Apple ID 下载和订阅，充值通过美区商店购买礼品卡，银联美元信用卡可直接支付。节点使用日本住宅 IP，且尽量保持固定。偶尔让在日本的朋友帮忙在手机上登录账号进行 chat 操作。
三个月使用下来，账号暂时安全。我没有修改电脑时区，也没有刻意回避中文——正常使用中文不应该是封号的理由，新加坡也有大量用户使用中文。
关于封号风险：我使用的是中档 Max 套餐，正常使用额度，并非每 5 小时都用满 200 刀的 Max 配额。听闻频繁跑满额度的账号更容易被封，可能是因为许多中转服务或拼车使用的是 20x Max 套餐，拉高了该档位的封号率。
万一账号被封，Plan B 是以 Codex 为主力。
印刷术让抄写员退出历史舞台，却没有消灭书籍——反而让思想传播得更快、更远。AI 带来的变革同理：手写代码这门手艺或许会褪色，但软件工程、以及「用代码解决真实问题」的价值不会消失。
技术革命淘汰的是具体的手艺，而非创造本身。
与其焦虑现有技能是否贬值，不如找到那根新的杠杆——让 AI 放大执行力，把判断、选择和责任牢牢握在自己。我们被推向更高的抽象层，这件事才刚刚开始。
保持乐观，拥抱这一进程吧。
关注最新 AI 动态,访问我的主页 http://my.arthaskj.top
