企业官网建设流程全解析

学AI编程的第五天，我没写新代码，而是把一个现成的Drumkit鼓声工具项目从头到尾拆了个底朝天。拆它的方式挺特别：全程用cc这个AI编程命令行工具来当讲解员。你可能听过Claude Code这个名字，cc是它的常用缩写，装进终端后就可以直接在项目目录里跟我对话。这篇文章记录的，就是我这一天怎么用cc去了解一个完全的项目——从整体结构到每一行关键逻辑，以及过程中踩到的两个真实翻车。

先交代一下背景。前四天我主要都在做"让AI帮我写功能"这种事：待办清单、倒计时器、表单校验。写出来的东西确实能跑，但我心里明镜似的——那些代码一旦离开AI，我单独面对，大概率是看不懂的。第五天我想换个方向：不再追求让AI写得更多，而是逼自己真正读懂一个项目。恰好朋友扔了个Drumkit项目给我，说是前端圈子里的入门经典，我就在这个项目上开启了这场"cc陪读"实验。

如果你是AI编程初学者，或者你经常陷入"AI生成一时爽，运行报错火葬场"的循环，这篇文章应该有参考价值。我会把实际敲过的提问、cc回答里的重点、还有翻车的过程尽可能原样写出来，不藏私。

1. 为什么拿Drumkit当"AI读项目"的练习素材

1.1 Drumkit是什么：一个九键鼓机

Drumkit来自前端圈很出名的JavaScript30课程，作者是Wes Bos。整个项目就三个文件：index.html、style.css、main.js，外加一个sounds文件夹放音效。页面打开后，键盘上的A、S、D、F、G、H、J、K、L一共九个键，分别对应clap、hihat、kick、openhat、boom、ride、snare、tom、tink这九种打击乐音色。按下任意键，对应的键位块会有一个变亮变大的小动画，同时播放音效，大约0.07秒后动画结束、键位恢复原状。

我特意数过，main.js的核心逻辑不到五十行。但就是这不到五十行，把前端最基础也最核心的几样东西全占齐了：键盘事件监听、DOM查询、音频播放、CSS过渡动画、class切换。放在前端语境里，这算是"麻雀虽小，五脏俱全"的典型。

1.2 为什么"读懂项目"比"让AI写项目"更适合现在的我

到了第五天我才想明白一个问题：让AI从空文件开始写东西，其实是个相对"低难度"的动作。你只要把需求描述清楚，它基本能给你一份能跑的代码。但真实工作里，你遇到的绝大多数代码都是别人写的，可能带着你看不懂的命名、分层、历史包袱。这时候AI能不能把别人的代码讲明白，才是它真正的价值分水岭。

Drumkit这种规模刚好处在练习"AI读项目"能力的甜点区间：文件少到AI不至于漏看，逻辑又完整到能给它展示跨文件理解的机会。要是选一个几百个文件的工程，新手很难验证AI讲得对不对；选Drumkit，我十几分钟就能把三个文件全部读完，cc说的每一句话我都能对着源码核实。这种"可验证性"对学AI编程的新手来说，实在太重要了。

1.3 工具选择：为什么用cc而不是别的AI编程助手

这几天市面上主流的AI编程工具我基本都试过一圈：有编辑器插件类的，有IDE内置类的，有网页对话类的。这次读项目我特意选了cc，理由有三个。

第一，cc是命令行工具，天然在项目目录里工作。我说的每句话它都带着当前项目的上下文去理解，不像网页版那样需要我把代码复制来复制去。第二，它支持长时间连续对话。读一个项目往往要连着问三四十轮，cc能记住整个对话上下文，前面聊过的后面不用重复交代。第三，它的回答明显偏"工程思维"，讲代码时会主动提到边界情况、设计权衡和反例，这些恰恰是新手最容易缺的东西。

当然，工具选择不是非此即彼，适合自己就好。但今天要讲的方法论——给AI定身份、分层提问、先猜后问、源码验证——换任何工具都好用。

2. 打开cc之前：我先自己做的三件事

2.1 用命令行确认目录家底

在把项目整个交给AI之前，我强烈建议你先自己看一眼目录。这不是浪费时间，而是在给后面的对话打"底稿"。我在终端里跑了一句：

ls -la

三秒钟后我就掌握了情况：Drumkit没有隐藏的node_modules，没有构建配置，就是三个源码文件加一个sounds音效目录。这意味着它不需要装依赖，不需要跑构建，直接双击index.html就能玩。这种零配置项目对AI读项目来说是最理想的——cc不用去理解打包工具、编译流程这些外围噪音，可以把全部注意力放在核心逻辑上。

顺便提醒一句，如果你拿到的是压缩包，记得先解压再进目录，别把整个压缩包直接丢给AI，它读不了打包内容。这种小事看着不起眼，真碰上了能卡你好几分钟。

我还数了一下sounds目录里的音频文件：九个.wav，正好和九个键一一对应。到这里我心里有个大概判断了：这个项目不需要后端，音频文件就是它的全部"数据"。

2.2 读HTML时抓到的关键线索：data-key是什么

接着我打开了index.html。第一眼有点懵，因为里面到处都是>function playSound(e) { const audio = document.querySelector(`audio[data-key="${e.keyCode}"]`); const key = document.querySelector(`.key[data-key="${e.keyCode}"]`); if (!audio) return; audio.currentTime = 0; audio.play(); key.classList.add('playing'); } window.addEventListener('keydown', playSound);

cc特意提醒我注意一个细节：这里用的是e.keyCode而不是e.key。keyCode是数字（A键是65），key是字符串（"a"）。为什么这个项目用keyCode？因为HTML和audio标签里存的就是>function removeTransition(e) { if (e.propertyName !== 'transform') return; e.target.classList.remove('playing'); } const keys = Array.from(document.querySelectorAll('.key')); keys.forEach(key => key.addEventListener('transitionend', removeTransition));

对应的CSS长这样：

.key { transition: all 0.07s ease; } .playing { transform: scale(1.1); border-color: #ffc600; box-shadow: 0 0 1rem #ffc600; }

这里藏着一个很隐蔽的坑：CSS里写的是transition: all，意思是transform、border-color、box-shadow三个属性都会发生过渡。每个属性过渡结束，都会触发一次transitionend事件。也就是说，如果不做过滤，removeTransition会被连续执行三次，结果是playing类被提前移除，动画效果闪烁、观感一下子变差。

解决办法就在事件对象上：transitionend事件自带一个propertyName字段，告诉你这次是哪个属性结束了。只要判断e.propertyName !== 'transform'就提前返回，只等transform这个"主效果"结束再删class，问题就解决了。cc说这个模式在动画编程里特别常见，学会一次，后面做拖拽、弹窗、手风琴菜单都会反复用到。

4.4 把三道门串成人话版本

听完cc的讲解，我试着把整个main.js转述成一段不带术语的人话：用户在键盘上按下一个键，浏览器把这次按键包装成事件对象；JS用事件对象里的keyCode，在全文档里找出对应的audio和按键块；找到之后先倒带、再播放，同时给按键块戴上一顶叫playing的"高亮帽子"；帽子一戴上，CSS开始跑过渡动画；动画跑完，transitionend事件发出信号，JS再把帽子摘下来，页面恢复平静。

这个过程本质是个"事件进、事件出"的闭环。cc让我拿这个闭环去套别的交互项目，我后来试了倒计时器和标签页切换，确实都能套得上。能把不同项目收敛到同一个模式里，我觉得才算真正"读懂"了。

5. 两次翻车：cc的讲解并不能盲信

5.1 翻车一：AI一本正经地编了个不存在的函数

拆到一半，我问了cc一个问题："main.js里的makeSound函数是做什么的？"cc几乎是立刻给出了一个像模像样的回答，说makeSound负责查找音频元素、触发播放，还顺带讲了一堆性能方面的考虑。

回答完我才觉得不对劲——我明明看过main.js，里面只有playSound，根本没有makeSound。我反问了一句："这个函数具体在文件哪一行？"cc支吾了一下，改口说可能是"常见Drumkit实现的其他版本"，并承认它参考了常见写法。

这件事让我后背后发凉。如果我不是提前读过源码，根本不会发现这是个幻觉，很可能把这个不存在的函数当成真知识记进脑子。从那一刻起我给自己定了一条铁律：cc给出的任何代码解释，都必须能在源码里找到对应位置，否则不采信。验证这个动作成本很低，几秒钟的事，但能挡住绝大多数的AI脑补。

5.2 翻车二："听懂了"其实是最大的假象

第二个坑更隐蔽，也更危险。cc的讲解实在太流畅了，每个逻辑都顺理成章，我一口气听完，心里冒出个念头："哇，我全都懂了。"

结果第二天我回忆Drumkit，发现自己只剩一个模糊印象——"好像是按键然后播放声音"，细节全还回去了。人脑有个毛病：理解一段流畅的叙述，会误以为自己掌握了知识，实际上只是"看过"而已。这跟刷短视频刷到觉得自己会做饭是一个道理。

我后来试了一个办法，意外地好用：让cc在每个主题讲完时给我出小测验，我答完它再批改。比如它当时考过我三个问题：

• 如果我想把音色换成钢琴音阶，需要改动哪几个文件？
• 为什么快速连按同一个键，声音还能从头播放而不是叠加？
• 如果把CSS里的transition: all改成transition: transform，removeTransition里的propertyName过滤还有必要吗？

第三个问题我答错了。我以为是"没必要了"，实际还是有必要——虽然过渡只剩一个属性时transitionend只会触发一次，但保留过滤逻辑，将来增加动画属性时代码依然稳健。这种被AI当面考倒的经历，比AI给我讲十遍都管用。

5.3 翻车之后我修正的三条铁律

两次翻车之后，我把使用cc的整套流程改成了三条铁律：

第一条，讲解必须落到源码。AI说到哪个函数，我就在编辑器里定位到哪个函数，定位不到就追问。任何讲不到行号的解释，大概率有水分。

第二条，每讲完一个主题，让cc出题考我。用输出倒逼输入，把"听懂了"变成"能答对了"才算完。

第三条，关键结论一定要动手验证。比如删掉currentTime = 0看是不是真的会连按失灵，改掉transition属性看动画会不会闪。能复现的结论才是自己的。

把AI当成"讲解员"而不是"权威"——这是今天这个项目教给我最核心的认知转变。

6. 第五天的三点收获与下一步打算

6.1 给AI配身份，是性价比最高的提示词

以前我以为提示词就是"把需求说清楚"，今天才体会到，"给AI一个身份"和"设定输出格式"带来的提升远比想象中大。同一个Drumkit项目，问"这代码是干什么的"和"你是我的导师，从设计意图开始讲这个项目为什么这么写"，得到的完全是两个量级的内容。给AI配好身份，就像给新员工发岗位说明书，它一下就知道该用什么标准工作了。

6.2 用真实项目长理解力，比刷教程扎实

前四天我刷了不少教程，刷的时候觉得全会，合上电脑全忘。但用Drumkit这个真实项目配合cc拆一遍之后，事件流、DOM查询、音频播放、CSS过渡这几个知识点，在我脑子里变成了有因果关系的链条，而不是一条条孤立的信息。项目逼着我把知识点串起来用，教程却在帮我一个个拆开讲。两相对比，哪个对新手更友好，我心里已经有答案了。

6.3 下一步：把Drumkit改造成自己的版本

第五天结束前，我给自己留了个作业：三天之内，尝试不依赖AI，自己默写并扩展一个Drumkit。比如给页面加一个M键来触发贝斯音色，或者把固定音色表改成页面上下拉选择动态切换。做不出来也没关系，卡住的时候再请cc当导师来提示，但绝不直接让它给完整答案。我始终觉得，从"能读懂"到"能改得动"之间，还差一段必须自己走的路。AI可以陪跑，但腿得长在我自己身上。

这个项目消化完，我应该会挑一个带后端的项目再做一轮同样的"cc陪读"。等把前后端都过一遍，我对"一个完整项目到底是怎么构成的"这件事，应该能建立起一个比较成体系的认知了。到时候如果又踩了什么新坑，再回来写一篇分享。