创建新文档

您的文档标题(将显示为 H1)
URL 友好名称(无空格,使用连字符)
创建文档的路径(可选,使用正斜杠创建子目录)

移动/重命名文档

文档的当前位置
文档的新路径(包括别名)
这只会更改文档的路径,不会修改文档的标题(H1 标题)。

删除文档

您确定要删除此文档吗?此操作无法撤销。

警告:如果这是一个文件夹,包括子文件夹和文档在内的所有内容将被删除。

Message

Message content goes here.

Confirm Action

Are you sure?

附件

允许的文件类型:jpg, jpeg, png, gif, svg, webp, txt, log, csv, sfd, zip, pdf, docx, xlsx, pptx, mp4(最大:10MB)

文档文件

正在加载附件...

文档历史

以前的版本

Loading versions...

预览

选择要预览的版本

Wiki 设置

用户界面语言
每个文档保留的版本数量。设置为0以禁用版本控制。
上传文件的最大允许大小(MB)。

用户管理

添加新用户

留空以保持当前密码
拥有这些组的用户可以访问受限部分。

为您的Wiki部分定义基于路径的访问规则。规则按顺序评估。首次匹配生效。

活动规则

从ZIP归档文件导入Markdown文件。文件将被处理并存储在适当的文档结构中。ZIP中的目录结构(类别/子类别)将在wiki中保留。

上传包含要导入的Markdown(.md)文件的ZIP归档(压缩包)。

创建和管理您的 Wiki 数据备份。备份包括所有文档、图像和配置文件。

可用备份

正在加载备份...

添加/编辑访问规则

已选择: /

添加列

Claude Code 开局技巧

我们平时兴冲冲打开 Claude Code,然后就开始瞎写代码(尤其是小白),结果项目越做越乱,最后发现自己在一堆烂摊子里挣扎?

这个视频里的老哥 Avthar 说他以前就是这么干的,直到他摸索出了一套叫 PSB 的系统——Plan(计划)、Setup(配置)、Build(构建),现在他每个项目都用这套流程,效率直接翻了 10 倍。

他说的第一个阶段是计划阶段,听起来似乎大家都知道对吧?但他强调花 15 分钟做计划能省你好几天的时间。

这个阶段核心就是问自己两个问题:

  1. 你到底想干什么?
  2. 你想要哪些功能里程碑?

比如你是在做原型验证还是要上线给真实用户,这完全决定了你的开发方式。

如果只是做原型,那就快速迭代不用管边界情况;但如果要上线,安全性、错误处理这些都得考虑进去。

他建议把项目拆成 MVP(最小可行产品)和后续几个版本,别想着一次做完所有功能。

然后他提到一个特别实用的技巧:

让 AI 来问你问题。

你把初步想法丢给 Claude,让它问你三个最重要的问题,通过回答这些问题你会发现很多自己没想清楚的地方。

他甚至会用语音模式跟 ChatGPT 聊天,把模糊的想法说出来,然后让 AI 整理成文档。

最后这个阶段要输出一个项目规格文档,包含产品需求和技术需求两部分。

产品需求就是你要解决什么问题、给谁用、具体交互是什么样;

技术需求就是选技术栈,他自己偏好的是 Next.js + Tailwind + Supabase 这套组合,但重点是你得明确告诉 Claude 用什么,不然它会自己瞎选。

第二阶段是配置阶段,他列了个七步清单。

首先是建 GitHub 仓库,这样你能在网页端和手机上用 Claude Code,还能用 GitHub CLI 和自动化 PR 审查。

然后是配置环境变量文件,把所有 API key 提前填好,省得 Claude 老是停下来问你。

接着是重头戏——CLAUDE.md 文件,这个文件会一直在 Claude 的上下文里,但不能塞太多东西。

他建议放项目目标、架构概览、设计规范、约束条件这些核心信息,其他详细内容可以链接到别的文档。

他特别强调自动化文档这个概念,就是让 Claude 在开发过程中自动更新几个关键文档:

architecture.md 记录系统设计、changelog.md 记录变更历史、project-status.md 记录当前进度和下次从哪继续。这样即使你几周没碰项目,回来也能快速接上。

然后是配置插件和 MCP(模型上下文协议)服务器,比如前端开发插件能避免那种千篇一律的紫色渐变 UI,数据库 MCP 能让 Claude 直接操作你的 MongoDB 或 Supabase。

最后是设置自定义命令和子代理,比如他有个命令专门用来更新所有项目文档,还有个子代理专门做前端测试。

两个高级技巧也值得一提:

一是预配置权限,让 Claude 不用每次都问你能不能运行 git 命令;
二是设置钩子(hooks),比如测试失败时自动让 Claude 继续修复,或者 Claude 需要权限时自动发 Slack 通知你。

第三阶段就是构建阶段了,终于可以写代码了。

他推荐三种工作流:

  1. 通用工作流适合单个功能开发,分为研究、计划、实现、测试四步,其中计划模式最重要,别上来就让 Claude 写代码;
  2. 基于 Issue 的工作流把 GitHub Issues 当作任务管理中心,适合保持项目整洁;
  3. 多代理工作流最高级,用 git worktrees 让多个 Claude 实例同时开发不同功能;

他试过同时开三个功能,效率爆炸。

最后他给了四个保持高效的建议:

  1. 尽量用最好的模型,Opus 4.5 做规划和复杂任务,Sonnet 做实现,Haiku 只做简单修复;
  2. 定期更新 claude.md 文件;
  3. 看到 Claude 犯错时用 # 号快速添加规则防止重复错误;
  4. 别怕扔掉代码,原型阶段如果不满意就重来,代码很便宜时间才贵。

他这套 PSB 系统确实很系统化,特别适合那种容易一头扎进代码然后迷失方向的人。

所以还是那句话,别急着写代码,宁愿花时间做好计划和配置,后面开发你会感觉顺畅得多。

https://x.com/i/status/2008591400317944135

附件

正在加载附件...

评论

暂无评论。成为第一个评论者!

搜索结果