2025-09-01 00:07:41
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/notes/197
我清晰的记得，从上半年的 Claude 4 出来之后，从我第一个项目 Afilmory 完全 vibe 出来之后，慢慢走上了不归路，开始越来越依赖 AI，而我只是一个 AI 的指挥。到后面一发不可收拾，先后用 AI 开发了 face-mask-web, exif-tools,Pastel。
在半个月前，我的 Claude Code 被封号了。一时间有点心灰意冷，一时间好像失去了创作的欲望，也充满了没有 AI 的恐惧。在离开两天后，我还是忍受不了没有 AI 的帮助，我再次购买 Claude Pro，即便是冒着封号的风险。
https://x.com/__oQuery/status/1956924069334663294
前不久，我又开通了 ChatGPT Plus，不得不说现在 AI 厂也是卷。用了 Codex 几天之后，我认为它的上限比 Claude Code 高，从模型上来说，Codex 的 GPT-5 上下文支持 300多万个，而 Claude Sonnet 4 最高只有 1M。上下文的长度让我可以不压缩对话，从始至终使用一个对话。例如之前和 Codex 聊的一个验证 app 完整性的方案。最后聊了 185 万个 token，上下文还有 55% 的剩余。记忆方面，聊到最后他还记得第一句聊的是什么。
前不久刚上线的 VSCode 的 Codex 扩展和全新的 Codex Cli，我真的感觉已经比 Claude Code 好用太多了。唯一的不足是，周用量太少了。我就用了三天就限流了，需要等到下个周一。
最近又开始起一个新坑了，对市面上的 Torrent WebUI 都不太满意，于是打算自己做一个。目前官网已经完成了，app 也差不多完成了最原始的功能。由于现在 AI 时代代码都不值钱，反而想法比代码值钱。所以这次不打算开源任何 AI 写的烂代码了，尝试一下商业模式，所以这次的 App 会进行买断制，现在加入 waitlist 可以获得优惠码。
官网贴这里了，https://torrent-vibe.app ，可以填写下 waitlist。
之前也去过几次湖州，当时虽然都去过了太湖边，但是唯独没有去过太湖古镇。那个时候还是不需要门票的，从今年八月开始需要门票了。入场门票是 60 元。
下午到达，进入后一度没看到人，周围还都是倒闭门店，人也没看到几个，天又热，还以为是又被小红书骗了。
一直往里走才到达热闹的地方，陆陆续续看到人和活跃的气氛，前面就是一个歌舞秀的演出「醉美太湖」，凭票可以免费观看。外面没有多少人，但是进到剧场之后看到满满的都是人。这大热天的还是在室内凉快。选了一个靠后一点的位置观看，刚开始并不知道是什么，后来知道是一个真人的演出。还好带了一个长焦，拉到 300 焦距刚好可以拍到舞台。
https://afilmory.innei.in/?tags=%E9%86%89%E7%BE%8E%E5%A4%AA%E6%B9%96
也是拍了不少照片，选了一些片上传到了我的图库。链接贴在上面了。
演出大概四十分钟，结束后跟着人流前往对面的剧场，观看俄罗斯冰秀，同样也是凭票进入。舞台是一个大型的溜冰场，出演的应该都是俄罗斯演员。
结束之后出来，人开始越来越多了。街上的 NPC 也比较多，有跳舞的，巡游的，也有玩小游戏的。
晚上的烟花和铁花表演，小红书诚不欺我，太壮观了。不是传统的打铁花表演。开场是一个表演，然后水上飞人的铁壶，伴随好几个船上开始打铁花，楼上的也开始打铁花，表演了几分钟之后，开始放起了烟花，低空+高空同时进行，太美了。选了一些片，放在下面了。
这一天，看了这么多演出，60 的门票也值回票价了。
最近一个月看了以下的电视剧：
https://www.themoviedb.org/tv/292575-the-narcotic-operation
2025-08-01 00:14:58
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/posts/tech/tailwindcss-v4-color-system-theme-switching-guide
在很久的时候我写过一篇文章使用一种便捷的方式去实现 dark mode 的颜色切换，简单来说就是用 CSS 变量实现的，替换了默认的所有的颜色色值。
https://innei.in/posts/programming/tailwind-built-in-colors-dark-mode
这样虽然也可以实现，但是局限性比较多，比如为了让颜色支持 Tailwindcss 的 /<alpha> 的语法，我们在定义颜色的时候得这样写：
module.exports = {
theme: {
colors: {
"material-opaque": "rgb(var(--color-materialOpaque) / <alpha-value>)",
},
},
}
此时的 CSS 变量的值并不是一个颜色值，而是一个字符串：
--color-materialOpaque-light: 246 246 246;
不仅在编辑器中无法直接看到颜色的呈现，修改起来也是难事。
最大的问题，如果设定的颜色本身带有透明度，那么 /<alpha> 的语法直接失效：
module.exports = {
theme: {
colors: {
"material-ultra-thin-light": "rgba(var(--color-materialUltraThin-light))",
},
},
}
/// CSS
--color-materialUltraThick-light: 246 246 246 / 0.84;
因为 CSS 颜色引用了透明度，将无法应用两次透明度。这直接导致 bg-material-ultra-thin-light/10 失效。
color-mix 是什么在 TailwindCSS 4 中，不在使用原先的方式去调整透明度，而是改用 color-mix() color-mix() 函数标记接收两个 <color> 值，并返回在指定颜色空间、指定数量混合后的颜色。
它是支持多种颜色进行混合的，那么对于本身是透明的颜色，也可以再进行一次混合。
在 TailwindCSS v4 中是这样调整透明度的。
bg-background-secondary/30
↓
color-mix(in oklab, var(--color-background-secondary) /* oklch(0.98 0.0049 230) = #f5f9fb */ 30%, transparent);
通过混色一个 transparent，控制 transparent 的深度来实现最终的透明。
对于本身就存在透明的颜色也是没有问题的：
.bg-material-thin\/20 {
background-color: color-mix(in oklab, var(--color-material-thin) /* oklch(0.96 0.0049 230 / 0.60) = #eff2f499 */ 20%, transparent);
}
@layer 层级控制场景下的颜色在 TailwindCSS v4 之前的版本，也已经大量使用 @layer 来控制 className 的优先级问题，但是这个声明都是 polyfill 的，在 PostCSS 中进行转义，实际在应用中并不会出现这个 layer。
在 V4 之后的版本中，已经默认使用 layer 控制层级。v4 和 v3 之前的版本最大的不同，就是 v4 不再需要在 js config 中定义新的颜色或者覆写自带的颜色。而是全部通过 CSS 实现的，这也是得益于 layer 的优势。在 TailwindCSS 所有定义都在 @layer theme 中，我们只需要在不同的时候覆写其变量值就可以了。
那么下面就是一个简单的例子，我们需要自动切换 light/dark，支持当 data-theme='cute' 时切换主题颜色到 cute 的颜色风格。
@import "tailwindcss";
/* Light mode colors (default) */
@theme {
--color-blue: oklch(0.65 0.18 237);
--color-pink: oklch(0.68 0.22 350);
--color-purple: oklch(0.65 0.2 280);
--color-green: oklch(0.67 0.15 155);
--color-orange: oklch(0.68 0.15 60);
--color-yellow: oklch(0.75 0.12 100);
}
首先使用 @theme 定义 TailwindCSS 颜色。@theme 在 浏览器中也是应用在 @layer theme 中，其目的让 TailwindCSS 识别配置。
然后控制在当 dark: 作用下的颜色：
@layer theme {
* {
/* Dark mode overrides */
@variant dark {
--color-blue: oklch(0.7 0.16 237);
--color-pink: oklch(0.73 0.2 350);
--color-purple: oklch(0.7 0.18 280);
--color-green: oklch(0.72 0.16 155);
--color-orange: oklch(0.73 0.16 60);
--color-yellow: oklch(0.78 0.14 100);
}
}
这里注意了，写成 @layer theme 而不是 @theme 因为这个是在浏览器中覆写的，而不是 TailwindCSS 的配置。
最后实现另类主题，我们可通过 data-theme 控制：
@layer theme {
[data-theme=cute] * {
/* Kawaii color overrides */
--color-blue: oklch(0.85 0.12 237);
--color-pink: oklch(0.87 0.16 350);
--color-purple: oklch(0.84 0.14 280);
--color-green: oklch(0.85 0.12 155);
--color-orange: oklch(0.86 0.12 60);
--color-yellow: oklch(0.9 0.1 100);
}
/* Kawaii dark mode overrides */
@variant dark {
--color-blue: oklch(0.65 0.14 237);
--color-pink: oklch(0.7 0.18 350);
--color-purple: oklch(0.67 0.16 280);
--color-green: oklch(0.68 0.14 155);
--color-orange: oklch(0.69 0.14 60);
--color-yellow: oklch(0.73 0.12 100);
}
}
同样另类主题也要适配 dark: 颜色适配。
至此我们实现了四套颜色的无缝切换。效果非常的好，在编辑器中也可以直接查看色值：
对比之前 V3 因为是变量，什么都看不到。而 V4 本身配置下的颜色就是变量，所以可以直接看到颜色了。
什么，你问这么好用的现代的 TailwindCSS V4 的颜色系统库在能哪里找到。那必须是我最新写的 Pastel。
https://github.com/Innei/Pastel
还不知道这个的赶快去点 Star，然后替换颜色定义！
2025-07-25 20:58:04
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/notes/196
死亡搁浅 2 通关通关了，玩了 50 个小时。和上一部作品一样，越是玩到后面越停不下来，修路修铁轨，去抢劫老乡。
我不是一直推主线的玩家，而是中间过程更多是做基建。有了前作的经验，我知道在剧情的最后一段，小岛秀夫肯定会安排一个任务是独自从地图的一端徒步到另一端，这个时候基建尤其重要。当主线剧情推进到十章以后时，我知道这个游戏剧情快迎来尾声了，而后面的章节很有可能整个都是播片。我非常喜欢电影型叙事，非常喜欢看剧情播片，死亡搁浅的剧情总是在前期埋下一万个问号，我总是忍不住想继续玩下去想知道为什么，总会有很多猜测很多误解，到最后，啊，原来是这样啊。剧情通关的时候，很不舍得，就这样结束了吗。
我是在完成主线剧情之后，才把所有的避难所连上开罗尔网络的。
然后又把三条单轨通车了。
高速全线通车还差一点点。
然后是游戏摄影，不得不说这个游戏的画面太好了，随手拍了几张：
:::gallery
:::
最近用 AI Coding 比较多，我已经越来越离不开 AI 了。
如何通过 AI 提效，通过 AI 在有限的时间内做更多的事情也是我一直在摸索的。
前几天我写了一篇关于 Context Engineering 的文章火了, 同时有一百个人再看，也是迎来建站以来最高的同时在线人数。
https://innei.in/posts/tech/ai-coding-methodology-systematic-practice
目前 AI 虽然很强，但是还是不能完全替代程序员，AI 编程最强的领域或许是 Web 相关技术栈，但是你要说他聪明的话，他连 React 现在都还写不好，总是写出违背 React 哲学的代码。我们作为最终决策者，是好是坏完全掌握在自己手中。为什么有人用 AI 写出来的 UI 或者产品很好看，有人用 AI 写的代码完全不可能维护，关键全在如何调教 AI，如果灌输 AI 正确的知识和引导正确的方向。我已经使用 AI 完全从 0 开始编写一个项目到可用，UI 协调，代码可维护好些项目了，后续也可以单独分享一下。我也非常赞同下面的观点：
总体来说，AI 带来的便利，更多的是让我们的想法能快速变现，很多想法在以前可能只是想想，永远没有时间和精力开始写下第一行代码，而现在我可以同时将多个想法并行实现，借助 AI 之力，尤其是开了 Claude Code 之后，我每时每刻都想着如何压榨 AI 替我实现愿望。从 Afilmory 到现在正在设计的一个 Tailwind 色盘 Pastel。
2025-07-17 23:07:50
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/posts/tech/ai-coding-methodology-systematic-practice
IMPORTANT 此文章由 AI 总结和润色内部分享，由笔者校对，请注意甄别。
作为 AI 辅助开发的最基础形态，提示工程采用离散式交互模式。开发者通过连续对话逐步细化需求，AI 基于即时反馈进行代码迭代。该模式在需求边界模糊、探索性强的场景中具有天然优势，但存在显著的效率瓶颈。
案例 1：高性能图片预览库开发
项目背景：构建基于 WebGL 的高性能图片预览解决方案
开发过程回溯：
在 afilmory 项目 中，初期采用纯对话式开发模式。经过数周的探索性开发，通过 20+ 轮次的需求澄清和架构重构，最终采用 Gemini-2.5-pro-preview-0605 进行系统性重写，产出 最终方案。
案例 2：Landing Page 重构
需求描述："重新构建 folo.is landing page 的 UI，使其现代化，AI 风格。样式参考 Vercel、Linear 的 landing page 设计"
交互过程可视化：
通过 12 轮精细化微调，涵盖：
该模式构建了需求澄清的系统性框架，将 AI 从代码实现者转变为架构顾问。通过结构化的需求勘探，显著降低后期重构成本。
探索式对话过程：
💡 关键提示：在探索式对话确定最终方案后，务必让 AI 将完整的架构决策、技术选型、接口设计等核心要素输出到结构化文档（如
ARCHITECTURE_DECISION_RECORD.md）。这能防止后续实现过程中因上下文窗口限制或记忆衰减导致的方向偏离，确保实现过程与既定方案保持严格一致。
实现从"AI 能做什么"到"AI 应该怎么做"的认知跃迁。通过构建完整的项目上下文，将隐性知识显性化，确保 AI 行为与项目规范高度一致。
1. PRD Specification Template
# Product Requirements Document (PRD)
## Objective
- [Clearly defined, measurable feature goals]
## Technical Constraints
- [Non-negotiable technical decisions]
- [Architectural principles that must be followed]
## Quality Standards
- [Performance benchmarks]
- [Maintainability requirements]
- [Test coverage criteria]
## Integration Requirements
- [External dependencies inventory]
- [Interface specifications]
## Deliverables Definition
- [Code organization patterns]
- [Documentation requirements]
2. Context Engineering Automation
https://github.com/coleam00/context-engineering-intro
PRD Generation Workflow:
Implementation Execution:
Core Commands:
/generate-prps: Generate technical implementation plan from PRD specifications/execute-prp: Execute development tasks according to predefined planAI 的认知受限于上下文窗口，无法完整理解项目所有细节。通过构建可维护的知识图谱，实现项目智慧的持续积累。
Claude Code：
# 初始化项目认知
/init
生成基础项目记忆，包括：
案例：UIKit 颜色系统规范
Prompt：
你应该使用 tailwindcss-uikit-color 文档是 https://github.com/Innei/apple-uikit-colors, 使用这个颜色系统去编写组件，这个规则写到 claude.md
AI 理解的规范化表达：
### UI/UX Guidelines
- Use Apple UIKit color system via tailwind-uikit-colors package
- Prefer semantic color names: `text-primary`, `fill-secondary`, `material-thin`, etc.
- Follow system colors: `red`, `blue`, `green`, `mint`, `teal`, `cyan`, `indigo`, `purple`, `pink`, `brown`, `gray`
- Use material design principles with opacity-based fills and proper contrast
i18n 规范示例
Prompt：
你在编写 i18n key 时，应该使用扁平 key，不能使用冲突的 key 如 exif.custom.rendered.custom 和 exif.custom.rendered，你应该遵循语言的规则；最后把这个规则写到 claude.md 中。
通过交互式反馈，将隐式约束转化为显式规则：
#### i18n Writing Guidelines
1. Follow [i18next formatting guidelines](https://www.i18next.com/translation-function/formatting)
2. **Use flat keys only** - Use `.` notation for separation, no nested objects
3. For plural-sensitive languages, use `_one` and `_other` suffixes
4. **Avoid conflicting flat keys** - During build, flat dot-separated keys (e.g., 'exif.custom.rendered.custom') are automatically converted to nested objects, which can cause conflicts.
Example:
```json
{
"personalize.title": "Personalization",
"personalize.prompt.label": "Personal Prompt",
"shortcuts.add": "Add Shortcut",
"shortcuts.validation.required": "Name and prompt are required"
}
```
SuperClaude 提供了一系列增强命令：
/document: 自动化文档生成/review: 代码质量审查/refactor: 重构建议在 ~/.claude/CLAUDE.md 中配置全局行为准则：
### Code Structure & Modularity
- **Never create a file longer than 500 lines of code.** If a file approaches this limit, refactor by splitting it into modules or helper files.
### Documentation & Explainability
- **Comment non-obvious code** and ensure everything is understandable to a mid-level developer.
- When writing complex logic, **add an inline `# Reason:` comment** explaining the why, not just the what.
### 🧠 AI Behavior Rules
- **Never assume missing context. Ask questions if uncertain.**
- **Never hallucinate libraries or functions** – only use known, verified packages.
- **Always confirm file paths and module names** exist before referencing them in code or tests.
- **Security** You are prohibited from accessing the contents of any .env files within the project.
AI 编码已从简单的代码生成演进为系统化的工程实践。关键认知转变：
最终，AI 工程的核心在于将人类的专业判断与 AI 的执行能力有机结合，在保持技术前瞻性的同时，确保交付物的工程质量和长期可维护性。
2025-07-12 12:53:16
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/notes/195
这篇文章记录一下最近一个月发生的事。
距离上次去南京差不多一年了。由于上次去只待了两天一晚就离开了，所以很多地方都没去，这次差不多待了 5 天了，就比较有充足的时间去一些有意思的地点。
和上次一样，也是住在朋友 Magren 家里。可惜朋友马上要离开南京去往另一座城市了，以后更加分隔千里，所以也是在这最后的时刻再相聚一回，顺便看看以前没见过的风景。
第一站，参观了下南京小米总部：
虽然那天是周末，但是公司还有同事在加班，然后就被朋友 LD 叫住加了半个小时的班。我有罪，都是因为我提议想去小米看看。
第二站，去了 MaxtuneLee 的学校，南邮。真巧的时候，Magren 因为工作将要离开南京，而 MaxtuneLee 因为毕业也即将离开南京。一下子再没有认识的人在南京了。
第三站，在中华门附近集市 - 老门东。
第四站，去了水游城。没拍到什么好的。主要是太社恐了。不过我这两位朋友还是很社牛的。邀请到了一位兽装小姐姐拍了一张。
第五站，去了南京最豪华的厕所。德基广场。
在厕所大厅聆听钢琴的弹奏。
去哈苏感受了一下裁神爷 - 哈苏 X2D 100C。惊人的解析力，1 亿像素。给大帅哥照了一张。
第六站：错觉博物馆
第七站： 红山森林动物园
图片太多就这里不发了。汇总都在这里了。
最近半个月都在全力开发 Folo 的初版 AI。目前的样子大概是这样的：
https://x.com/__oQuery/status/1943340600520306937
https://x.com/__oQuery/status/1940439201612525959
用的是 Vercel 的 AI SDK，总体用下来是比较方便的，但是性能上只能说一坨。流式的时候所有的都在 render 就很卡。最离谱的时候只有几帧，卡的没啥用。后面要专门治理这个性能问题了。大概的方向是两个：Markdown parser 的提速和减少 message 的 render。
目前来看整体的 UI/UX 还行，接下来就是性能了。
自从上次买了坚果 N3 之后，因为不支持杜比视界退货了。后来又买了一台 Vidda C3S，5k 的价位支持杜比视界。
投一百多寸送快递还是挺爽的。
最近七月番好看的还挺多的，我大概会最下面的这些：
不算太晚购入了 死亡搁浅 2 冥滩之上，到现在大概送了四十个小时快递了，每天沉迷送快递修路，不亦乐乎。
欢迎来加我 PSN 好友：@innei_j，一起修路。
太美了。
目前的地图：
:::gallery
:::
