跳到正文
AI 不释手

搜索文章

搜索本站已发布的 AI 内容。

本文目录

和 AI 一起,把想法做成

预计阅读 5 分钟(约 1,900 字)体系总览
开发者拿着检查清单,与 AI 小机器人把草图搭成网站,桌上摆着蓝图与经验笔记。

AI 开始写代码之后,怎样确认目标没跑偏、结果用得上、下次接得住?从本站的真实改版,看一套 AI 开发方法怎样落地。

“帮我把首页整理一下。”

这句话足够让 AI 开始写代码,却还没说清:读者来这里找什么,哪些入口要保留,怎样才算整理好了。等它交回页面,还得确认手机上读不读得下去;换一轮对话,也得有人知道工作停在哪里。

我在这个网站里实践的,就是怎样把这些问题接起来:先判断值得做什么,把期待变成可检查的约定,让 AI 带着必要的上下文实现,再用结果检验,留下下次用得上的经验。 人负责目标、取舍与验收,AI 承担已确认范围内的实现和检查。

下面这张图是整篇的阅读地图。前五个专题讲方法,第六个把它们放回本站的真实改版中。你可以顺着读,也可以直接去看眼下卡住的那一步。

  1. 价值决策值得做吗?
  2. 任务约定怎样算做好?
  3. 上下文工程从哪里接着做?
  4. 产物验证凭什么说完成?
  5. 经验沉淀下次能复用什么?
工程实践在真实项目里使用,把结果与问题带回前面的判断。
这是一条可以回头的工作路径。验证发现目标或约定有遗漏,就回到相应位置修正。

先想清楚,再动手 ​

AI 很快能做出一个功能,会让“要不要做”听起来像“能不能做”。可页面生成之后,内容还要更新,入口还要维护,问题没有因此消失。

本站就遇到过这个选择:AI 实践、投资研究、健康计划和工具,各有用途,要不要都放到首页?这次改版选择先把“我怎样与 AI 一起开发”讲清楚,其他内容不自动进入新站。依据是已经确认的产品方向;它是否更受读者欢迎,还需要真实反馈。

因此,我会先问:谁遇到了什么问题,做成之后希望改变什么? 再看现有办法是否够用。目标清楚、成本低的小改动可以轻量决定;方向不明、投入又大的想法,先找证据,或缩小成一次尝试。

把“差不多”说清楚 ​

目标有了,一句“去掉导航栏”仍可能有两种理解:撤掉顶部栏目菜单,还是连左侧专题入口也一起去掉?两种页面都能做出来,阅读结果却不同。

本站最终确认的是:撤掉全站和栏目菜单,保留左栏的专题、热门标签与推荐阅读;右侧目录只定位当前文章。把这些边界说出来,AI 才有共同的实现依据。

一份小任务约定,可以先说到这个程度:

例如,改一页文章:调整正文和图文表达,保留已有阅读入口;完成后检查构建、桌面与手机页面,交给作者验收。本轮只做本地预览。

约定的长短跟着任务走。关键是明确改什么、保留什么、怎样检查,以及哪些动作已经获准;出现会改变结果的新选择,再回来讨论。

让 AI 接得住,也接得下去 ​

今天改完页面,明天新开一轮对话,输入“继续开发”。如果只留下“基本完成”,接下来该改内容、补验证,还是等验收,谁也说不准。

我让项目留下三层路标。本站的 AGENTS.md 负责指路,计划中的 Now 保存当前任务,代码、配置与检查结果负责回答实际状态。按这个顺序,AI 能找到恢复工作的起点,再读取这次真正相关的材料。

这类任务,先看哪里?项目约束与任务路由
AGENTS.md
上次停在哪里?当前状态、剩余检查与下一步
Now
系统实际是什么样?读取源码,核对已有改动与检查结果
代码 · 配置 · 检查
路由帮助找到资料,接续记录说明下一步,实际产物用来核对;三者各有职责。

例如,“正文已改,桌面已检查,手机目录还没验证;下一步检查窄屏目录”,就比“完成了 80%”更能指导行动。这是一条示例记录。真实任务要留下当时的状态,旧记录失效时也要更新。

反复使用的一类工作,再整理成按需调用的 Skill。入口保持简短,细节在需要时展开,避免每轮对话都先塞进全部历史。

它说完成了,然后呢? ​

假设 AI 说:“手机目录已经修好。”构建通过了,截图里也有一个目录按钮。这些还回答不了:按钮能不能打开,选中小节后是否定位正确,关闭时焦点会回到哪里。

我会把“完成”拆成可以实际回答的问题。以本站阅读页面为例:

检查要回答的问题仍不能证明什么
完整构建这轮源码能生成页面吗?目录按钮能否操作
浏览器操作在受测屏幕上,打开、定位、关闭是否可用?未覆盖的设备与路径也可用
作者验收内容和阅读效果符合预期吗?已经上线,或阅读量已经提升

检查跟着可能失败的地方走。改了目录,就操作目录;改了返回逻辑,就实际前进、后退。结论只说到证据能支持的地方。 哪项还没验证,直接留下缺口,下一轮才知道从哪里继续。

让下一次少踩一个坑 ​

验证发现一个坑,修完就结束,下一次可能重来;每次都加一条永久规则,项目又会越来越难读。留下什么,需要再做一次选择。

本站搜索入口有一条具体约束:桌面上相对整个视口居中。页面有侧栏时,如果改成相对正文容器居中,位置就会偏。这条经验值得留下的是“以视口为参照”的意图,以及检查时要覆盖不同布局的原因。具体 CSS 仍以代码为准。

我的选择是:能稳定自动判断的,交给代码与检查;需要人理解的,写清条件与理由;只属于这次任务的,留在任务状态里。已经过时的内容及时修正。经验有没有用,要看下次是否帮助了实际判断。

这个网站,就是实践现场 ​

本站这次阅读改版,把几项方法串在了一起:先确定聚焦 AI 开发体系,再说清菜单与阅读入口的边界,留下能接续的任务状态,用构建和浏览器操作检查,把值得复用的约束留回项目。

这里会把选择、变化、结果与局限一起公开。主页、专题与文章沿着同一条主线展开;目前还没有证据证明这次改版已经提升访问量。

如果你也正准备让 AI 改一个页面,可以先试三件小事:写清希望改变什么,挑一个最可能出错的操作去检查,结束时留下一条能接着做的记录。再到下面的案例里,看看这些做法在本站怎样展开。