diff --git a/website/blog/2025-01-15-engineering-practice-doing-small-things-well.md b/website/blog/2025-01-15-engineering-practice-doing-small-things-well.md index f04780a..e7720c4 100644 --- a/website/blog/2025-01-15-engineering-practice-doing-small-things-well.md +++ b/website/blog/2025-01-15-engineering-practice-doing-small-things-well.md @@ -1,10 +1,17 @@ --- slug: engineering-practice-doing-small-things-well -title: "工程实践分享 | 把小事做好" -authors: [techcamp] -tags: [ai, architecture, best-practices, career, compiler, engineering, go, tutorial] +title: 工程实践分享 | 把小事做好 +authors: +- techcamp +tags: +- ai +- architecture +- career +- compiler +- engineering +- go date: 2025-01-15 -description: "在日前举办的第三期 1024 实训营结营成果展示会上，导师杨寒星基于同学们的展示，分享了他的一些看法，也阐述了为什么做好小事对开发者的个人成长具有积极的意义。" +description: 在日前举办的第三期 1024 实训营结营成果展示会上，导师杨寒星基于同学们的展示，分享了他的一些看法，也阐述了为什么做好小事对开发者的个人成长具有积极的意义。 --- 在工程实践中，做好小事非常重要。 @@ -14,20 +21,20 @@ description: "在日前举办的第三期 1024 实训营结营成果展示会上 * 杨寒星 GitHub：https://github.com/nighca ## 一些启发 -![pic-1](/img/blog/engineering-practice-doing-small-things-well/11111.png) +![pic-1](/img/blog/工程实践分享-把小事做好/11111.png) 要在3个月内实现Go+ Builder向导系统，这是一个复杂且工作量巨大的任务。同学们需要涵盖从调研到设计再到实现的整个流程。而且，Go+ Builder项目已有一定基础，需在此基础上进行设计、添加功能和编写代码，必然会面对一定的复杂性。此外，同学们还需在实现过程中解决许多具体问题（例如，如何实现代码检测）。 这个过程对我也有一些启发。以代码检测为例，我们在设计这一功能时，考虑过逐字符匹配、正则表达式，甚至通过编译器解析代码并检查抽象语法树（AST）来判断用户输入是否正确。经过多种方案的思考，我们最终想到利用大模型解决这个问题。这是一个典型的例子，展示了大模型如何改变我们既有的交互范式，进而影响我们解决问题的方式。 ## 把小事做好 -![pic-2](/img/blog/engineering-practice-doing-small-things-well/22222.png) +![pic-2](/img/blog/工程实践分享-把小事做好/22222.png) 这次实训过程，因为时间紧、任务重，我们在过程中对很多“似乎暂时不影响功能实现”的细节关注得并不多，但今天我想借这个机会再来分享一下，我是如何看待这些“小的事情”的。 小事是指哪些事情呢？它可能包括：是否在设计/产品/技术文档中进行了精准的表述、文档的格式细节是否正确、每个模块在集成之前是否做了充分的自测、代码中的实例在生命周期结束时其副作用是否被正确清理、类型安全问题、在做复杂客户端应用时经常面临的时序问题等等。 -![pic-3](/img/blog/engineering-practice-doing-small-things-well/33333.png) +![pic-3](/img/blog/工程实践分享-把小事做好/33333.png) 无论是文档方面，还是代码方面，这些“小事”暂时不处理似乎也没什么问题，反正项目可以继续、功能也能实现、用户也能使用，但其实，把小事做好，无论是对项目，还是对个人，都是很有意义的。今天，我们主要谈谈，“把小事做好”对个人的积极意义。 diff --git a/website/blog/2025-01-19-why-you-should-join-1024-techcamp.md b/website/blog/2025-01-19-why-you-should-join-1024-techcamp.md index 7f9cc38..74aeae4 100644 --- a/website/blog/2025-01-19-why-you-should-join-1024-techcamp.md +++ b/website/blog/2025-01-19-why-you-should-join-1024-techcamp.md @@ -1,19 +1,28 @@ --- slug: why-you-should-join-1024-techcamp -title: "同学，为什么我建议你关注 1024 实训营？" -authors: [techcamp] -tags: [ai, architecture, best-practices, career, compiler, engineering, go, llgo, xgo] +title: 同学，为什么我建议你关注 1024 实训营？ +authors: +- techcamp +tags: +- ai +- architecture +- career +- compiler +- engineering +- go +- llgo +- xgo date: 2025-01-19 -description: "2023 年底，我幸运地通过 1024 创作节获得了参加第一届 1024 实训营的机会,这次经历彻底改变了我对技术学习和职业发展的认知。" +description: 2023 年底，我幸运地通过 1024 创作节获得了参加第一届 1024 实训营的机会,这次经历彻底改变了我对技术学习和职业发展的认知。 --- 2023 年底，我幸运地通过 1024 创作节获得了参加第一届 1024 实训营的机会,这次经历彻底改变了我对技术学习和职业发展的认知。 与其他公司的实习不同，七牛云的实训营不是简单地让我们熟悉业务或写代码，而是提供了一个完整的项目实战机会。在实训营中，我们完整经历了技术选型、需求分析、架构梳理、模块拆分、实际编码测试，最终到上线和路演的整个软件开发生命周期。这种全方位的实战体验，让我第一次深刻理解了 1024 实训营"实践驱动成长"的培养理念。 -实训过程中最令我印象深刻的是导师们对工程质量的极致追求。一个 PR 经常被来回 review 三四十条 comment，比如 [PR#122](https://github.com/goplus/builder/pull/122) 和 [PR#96](https://github.com/goplus/builder/pull/96)。从前端构建过程到代码实现、从工程规范到部署落地，导师们以几乎"苛刻"的态度对待每一个技术细节。这种严谨的工程文化深深影响了我，至今在我的工作中，我仍然保持着对 PR 质量的高标准要求。 +实训过程中最令我印象深刻的是导师们对工程质量的极致追求。一个 PR 经常被来回 review 三四十条 comment，比如 [https://lt;https://github.com/goplus/builder/pull/122\](https://lt;https://github.com/goplus/builder/pull/122\)gt; 和 [https://lt;https://github.com/goplus/builder/pull/96\](https://lt;https://github.com/goplus/builder/pull/96\)gt;。从前端构建过程到代码实现、从工程规范到部署落地，导师们以几乎"苛刻"的态度对待每一个技术细节。这种严谨的工程文化深深影响了我，至今在我的工作中，我仍然保持着对 PR 质量的高标准要求。 -![pr-review](/img/blog/why-you-should-join-1024-techcamp/pr-review.png) +![pr-review](/img/blog/同学为什么我建议你关注-1024-实训营/pr-review.png) 在接口设计阶段，导师们也不会简单地告诉我们“应该怎么做”，而是引导我们思考：这个接口的核心需求是什么？未来可能如何演变？当前设计是否存在潜在问题？这种启发式的教学方式培养了我的系统思维能力和前瞻性设计意识，受益匪浅。 @@ -25,7 +34,7 @@ description: "2023 年底，我幸运地通过 1024 创作节获得了参加第 每一层技术挑战都有实力强悍的导师耐心指导。这种阶梯式的学习路径让每个人都能找到适合自己的成长方向。 -目前我正在负责 XGo 的底层编译器 LLGo 的子项目——llcppg，旨在自动生成 C/C++ 库的 LLGo Binding。通过这个项目，我不仅更深入理解了 C 编译器工作原理，也更理解了不同语言在设计其语法特性时的思考，还经常能从这一角的开源实践，窥探到整个软件工程的历史。在开发过程中也经常会得到导师们的经验上的分享、以及在架构设计方面的持续指导，这段经历成为我技术成长的重要里程碑。对于该工程的相关技术细节我专门写了一篇文章分享（[https://mp.weixin.qq.com/s/cx9F5lYKyxwvFpokicJ8Yw](https://mp.weixin.qq.com/s/cx9F5lYKyxwvFpokicJ8Yw)），项目代码也已开源在 GitHub（[https://github.com/goplus/llcppg](https://github.com/goplus/llcppg)），欢迎沟通交流。 +目前我正在负责 XGo 的底层编译器 LLGo 的子项目——llcppg，旨在自动生成 C/C++ 库的 LLGo Binding。通过这个项目，我不仅更深入理解了 C 编译器工作原理，也更理解了不同语言在设计其语法特性时的思考，还经常能从这一角的开源实践，窥探到整个软件工程的历史。在开发过程中也经常会得到导师们的经验上的分享、以及在架构设计方面的持续指导，这段经历成为我技术成长的重要里程碑。对于该工程的相关技术细节我专门写了一篇文章分享（[https://lt;https://mp.weixin.qq.com/s/cx9F5lYKyxwvFpokicJ8Yw\](https://lt;https://mp.weixin.qq.com/s/cx9F5lYKyxwvFpokicJ8Yw\)gt;），项目代码也已开源在 GitHub（[https://lt;https://github.com/goplus/llcppg\](https://lt;https://github.com/goplus/llcppg\)gt;），欢迎沟通交流。 可以说，实训营的经历直接影响了我现在的工作方式： diff --git a/website/blog/2025-01-21-engineer-core-competitiveness-in-ai-era.md b/website/blog/2025-01-21-engineer-core-competitiveness-in-ai-era.md index 23e4dc3..a78d2b3 100644 --- a/website/blog/2025-01-21-engineer-core-competitiveness-in-ai-era.md +++ b/website/blog/2025-01-21-engineer-core-competitiveness-in-ai-era.md @@ -1,10 +1,15 @@ --- slug: engineer-core-competitiveness-in-ai-era -title: "当 AI 能写代码，工程师的核心竞争力是什么？" -authors: [techcamp] -tags: [ai, architecture, career, engineering] +title: 当 AI 能写代码，工程师的核心竞争力是什么？ +authors: +- techcamp +tags: +- ai +- architecture +- career +- engineering date: 2025-01-21 -description: "Programming is changing so fast。" +description: Programming is changing so fast。 --- Programming is changing so fast。 diff --git a/website/blog/2025-01-23-qualities-of-excellent-engineers.md b/website/blog/2025-01-23-qualities-of-excellent-engineers.md index 7f066ad..6df2a25 100644 --- a/website/blog/2025-01-23-qualities-of-excellent-engineers.md +++ b/website/blog/2025-01-23-qualities-of-excellent-engineers.md @@ -1,10 +1,15 @@ --- slug: qualities-of-excellent-engineers -title: "我眼中的优秀工程师特质" -authors: [techcamp] -tags: [ai, architecture, best-practices, career, engineering] +title: 我眼中的优秀工程师特质 +authors: +- techcamp +tags: +- ai +- architecture +- career +- engineering date: 2025-01-23 -description: "在工作中我们会遇到各种各样的工程师，优秀的工程师会让项目的进展更顺利、产品的质量更有保障，与他们的合作也会让人感到愉快。" +description: 在工作中我们会遇到各种各样的工程师，优秀的工程师会让项目的进展更顺利、产品的质量更有保障，与他们的合作也会让人感到愉快。 --- 在工作中我们会遇到各种各样的工程师，优秀的工程师会让项目的进展更顺利、产品的质量更有保障，与他们的合作也会让人感到愉快。 diff --git a/website/blog/2025-01-25-why-end-files-with-newline.md b/website/blog/2025-01-25-why-end-files-with-newline.md index 0284490..9d58340 100644 --- a/website/blog/2025-01-25-why-end-files-with-newline.md +++ b/website/blog/2025-01-25-why-end-files-with-newline.md @@ -1,13 +1,17 @@ --- slug: why-end-files-with-newline -title: "一行之差：为什么你的文件末尾应该留一个空行？" -authors: [techcamp] -tags: [ai, best-practices, engineering, go] +title: 一行之差：为什么你的文件末尾应该留一个空行？ +authors: +- techcamp +tags: +- ai +- engineering +- go date: 2025-01-25 -description: "> ![github-no-nl-marker](github-no-nl-marker.png)" +description: '> ![github-no-nl-marker](/img/blog/一行之差为什么你的文件末尾应该留一个空行/github-no-nl-marker.png)' --- -> ![github-no-nl-marker](/img/blog/why-end-files-with-newline/github-no-nl-marker.png) +> ![github-no-nl-marker](/img/blog/一行之差为什么你的文件末尾应该留一个空行/github-no-nl-marker.png) > > “咦？怎么 GitHub PR 里多了个 ⛔️ 小红标？” > diff --git a/website/blog/2025-02-04-github-pr-merge-strategies-which-to-choose.md b/website/blog/2025-02-04-github-pr-merge-strategies-which-to-choose.md new file mode 100644 index 0000000..c43edc4 --- /dev/null +++ b/website/blog/2025-02-04-github-pr-merge-strategies-which-to-choose.md @@ -0,0 +1,130 @@ +--- +slug: github-pr-merge-strategies-which-to-choose +title: GitHub PR 合并三选一：主分支该怎么选？ +authors: +- techcamp +tags: +- ai +- architecture +- engineering +date: 2025-02-04 +description: '> ![GitHub PR merge menu](/img/blog/github-pr-合并三选一主分支该怎么选/github-pr-merge-menu.png)' +--- + +> ![GitHub PR merge menu](/img/blog/github-pr-合并三选一主分支该怎么选/github-pr-merge-menu.png) +> +> 在每个 PR 的底部，GitHub 都会给出三个合并选择。大多数开发者会习惯性地点击默认选项，但这个看似简单的决定却深刻影响着项目历史。 +> +> 今天我们来聊聊：为什么这个选择如此重要，以及为什么我坚持只用其中的一个。 + +## TL;DR + +**对指向主分支的 PR，一律选择 `Squash and merge`。** + +配合 [rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) 开启 [`Require linear history`](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-linear-history)，把线性历史与回滚边界制度化，从源头避免误操作。 + +## 核心原则：one PR, one commit + +**一个 PR 最终只对应主分支上的一个 commit。** + +PR 内部发生的多个 commits 都是开发阶段的中间态。历史被合并进主分支的那一刻，维护者更关心“结果”，也就是合并时那个版本的变更。需要更细的过程与讨论，可以通过 commit message 中的 PR 链接进入 PR 页面回看所有细节。 + +这个原则与 GitHub 的 `Squash and merge` 天然契合：一件事，一个节点，边界清晰。 + +## 三种方式全面对比 + +| 维度 | Create a merge commit | Rebase and merge | Squash and merge | +|------|-----------------------|------------------|------------------| +| **历史结构** | 产生 merge commit，主分支出现分叉 | 把 PR 的每个 commit 接到主分支，历史线性 | 把整个 PR 压成一个 commit 进入主分支，历史线性 | +| **协作影响** | 图谱更杂，阅读与 bisect 成本上升 | 改写 commit hashes，评论锚点与外部引用容易受影响 | 主分支整洁，release notes 更直观，审计与回滚成本更低 | +| **代码审计** | 需要追踪分支拓扑，复杂度高 | Commit hash 变化影响引用 | 线性历史，一目了然 | +| **版本回滚** | `git revert -m` 回滚合并节点，语义复杂 | 可逐条或成组回滚 | `git revert ` 一键整块撤回 | +| **Git bisect** | 在合并点容易困惑 | 可能命中中间态 | 每个 commit 都是完整功能态 | +| **生成 changelog** | 混合修修补补的小 commits | 同样包含中间 commits | 直接基于 PR 生成，语义清晰 | + +**本文主张**：主分支只接受 `Squash and merge`。 + +## 为什么选择 `Squash and merge` + +基于上面的对比分析，`Squash and merge` 的核心优势在于： +- **历史整洁**：线性历史，加上一个 PR 一个 commit，主分支成为清晰的时间轴 +- **操作简单**：回滚用 `git revert `，发布用 PR 生成 changelog，边界明确 +- **协作友好**：避免已存在 commit 的 hash 被重写，保持评论和审计完整性 + +这些优势让 `Squash and merge` 成为团队协作的最佳选择。 + +## 潜在担忧与应对 + +### 信息粒度损失 + +Squash 会丢失分支内的细粒度 commits。 + +**解决方案**：在合并对话框里写好一条高质量的 commit message，正文包含动机、设计取舍、风险与兼容性影响、迁移指引，并保留 `Co-authored-by`。细粒度历史保存在 PR 页面，随时可溯源。 + +### 复杂功能的开发过程追踪 + +对于包含多个开发阶段的复杂功能，有些团队希望保留详细的开发轨迹。 + +**解决方案**：建议将复杂功能拆分成多个独立 PR。如需保留内部开发结构，可在长期功能分支或发布分支间使用 merge commit，主分支仍用 squash 保持整洁。 + +## 配置指南 + +### 个人项目配置 + +如果是项目 owner，可以直接在仓库设置中限制合并方式： +1. 进入仓库的 `Settings -> General -> Pull Requests` +2. 勾选 `Allow squash merging` +3. 取消 `Allow merge commits` +4. 取消 `Allow rebase merging` + +### 团队项目强制约束 + +对于团队协作，建议使用 rulesets 进行强制约束： +1. **创建分支保护规则** + - 进入仓库的 `Settings -> Rules -> Rulesets -> New branch ruleset` + - 勾选 `Require linear history` 强制线性历史 +2. **应用到目标分支** + - 将创建的规则应用到主分支或使用匹配模式覆盖多个分支 + +### Commit message 编写规范 + +- **标题**：使用 PR 标题，简洁描述变更内容 +- **正文**：详细说明变更动机、技术方案、潜在风险和迁移指引 +- **溯源信息**：保留 PR 链接和 `Co-authored-by` 列表，便于追溯 +- **格式约定**：如团队使用 [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)，请遵循相应格式 + +### 问题回滚方案 + +- **图形界面**：在 PR 页面点击 `Revert` 按钮，自动生成回滚 PR +- **命令行操作**：执行 `git revert `，然后创建新 PR 提交回滚 + +## 常见问题与解决方案 + +### Q：为什么不选择同样线性的 `Rebase and merge`？ + +**A**：Rebase 会在合并时改写 commit hashes，容易打断评论锚点、外部引用和审计链。将 rebase 的复杂性留在分支阶段更稳妥，主分支只接受最终结果。 + +### Q：`Squash and merge` 会丢失贡献者信息吗？ + +**A**：不会。在合并对话框中使用 `Co-authored-by` 即可保留所有贡献者信息，PR 页面也会完整保存讨论记录和检查结果。 + +### Q：现有项目已有很多 merge commits，如何迁移？ + +**A**：新规则只影响未来的 commits。建议先为主分支启用 ruleset，在新 PR 中采用 squash，不要重写已有历史以免影响协作。 + +### Q：团队成员习惯了 `Create a merge commit`，怎么推动改变？ + +**A**：建议分步推进： +1. 分享线性历史的好处和实际案例 +2. 先在新项目中试验 squash-only 策略 +3. 为现有项目设定一个切换时间点，提前通知所有成员 + +## 今天就行动起来 + +**主分支是团队的时间轴，让它保持清晰。** + +复杂的开发过程留在分支中讨论，最终的成果用一个明确的 commit 记录在主分支上。这不仅是技术规范，更是对未来维护者的尊重。 + +现在就打开你的项目设置页面，将合并方式调整为 squash-only，你的团队（和未来的自己）会感谢你。 + +**记住：one PR, one commit. Keep master clean.** diff --git a/website/blog/2025-02-06-what-makes-ai-application-complete.md b/website/blog/2025-02-06-what-makes-ai-application-complete.md index b552847..c4461a1 100644 --- a/website/blog/2025-02-06-what-makes-ai-application-complete.md +++ b/website/blog/2025-02-06-what-makes-ai-application-complete.md @@ -1,54 +1,119 @@ --- slug: what-makes-ai-application-complete -title: "如何才算\"完成\"一个AI应用" -authors: [techcamp] -tags: [ai, engineering, best-practices] +title: 如何才算完成一个AI应用 +authors: +- techcamp +tags: +- ai +- engineering +- architecture date: 2025-02-06 -description: "调通了大模型接口 ≠ 完成了 AI 应用。AI 应用的本质不是技术演示，而是利用 AI 技术解决真实世界中的某个具体问题。" +description: 调通了大模型接口≠完成了AI应用。本文探讨AI应用的本质和完成标准。 --- ## 引言：现象与误区 -最近公司正在搞实训营，而我也有幸作为带教导师参与其中，期间也跟许多同学和助教聊到他们正在做的 AI 应用的相关问题，给我最大的感受是同学们有一个普遍的认知误区 ———— 调通了大模型接口 ≈ 完成了 AI 应用。这是一个需要澄清的关键认知偏差。 +最近公司正在搞实训营,而我也有幸作为带教导师参与其中,期间也跟许多同学和助教聊到他们正在做的 AI 应用的相关问题,给我最大的感受是同学们有一个普遍的认知误区 ———— 调通了大模型接口 ≈ 完成了 AI 应用。这是一个需要澄清的关键认知偏差。 -AI 应用的本质，不是技术演示，而是利用 AI 技术解决真实世界中的某个具体问题。因此，判断一个 AI 应用是否"完成"，核心标准在于：它是否达到了设计之初设定的解决特定领域问题的目标。 +AI 应用的本质,不是技术演示,而是利用 AI 技术解决真实世界中的某个具体问题。因此,判断一个 AI 应用是否"完成",核心标准在于:它是否达到了设计之初设定的解决特定领域问题的目标。 ## 为何"调通模型"远远不够？ -模型≠应用，大模型就像一台强大的引擎。把引擎装上车壳，不等于就造好了一辆能上路的汽车。 +模型≠应用,大模型就像一台强大的引擎。把引擎装上车壳,不等于就造好了一辆能上路的汽车。 -单纯的模型是有局限性的： +单纯的模型是有局限性的: -1. 知识边界：缺乏特定领域知识，在解决特定领域问题时，可能会答非所问 -2. 幻觉：模型可能自信地输出错误或捏造的信息 -3. 缺乏特定任务定制：通用模型不一定擅长你的特定任务，比如需要复杂的决策链路才能得到的答案 -4. 可控性与未知性：如果没有特别要求输出的规则与风格，往往每次输出都飘忽不定 -5. 场景复杂性：业务场景往往是复杂的，涉及多步骤，多信息源，特定逻辑和交互等。单纯调用大模型返回的文本很难满足用户需求 +1. 知识边界:缺乏特定领域知识,在解决特定领域问题时,可能会答非所问 +2. 幻觉:模型可能自信地输出错误或捏造的信息 +3. 缺乏特定任务定制:通用模型不一定擅长你的特定任务,比如需要复杂的决策链路才能得到的答案 +4. 可控性与未知性:如果没有特别要求输出的规则与风格,往往每次输出都飘忽不定 +5. 场景复杂性:业务场景往往是复杂的,涉及多步骤,多信息源,特定逻辑和交互等。单纯调用大模型返回的文本很难满足用户需求 -所以：模型只是基石，单纯靠调通大模型是无法构建一个可靠的，可用的，有价值的应用。 +所以:模型只是基石,单纯靠调通大模型是无法构建一个可靠的,可用的,有价值的应用。 -## 如何做一个有价值 AI 应用 + -往往有价值的 AI 应用（产品），都是瞄准某一个特定领域，解决某一个特定领域的问题，而在做 AI 应用前，需要想清楚我们的应用是要解决什么样的问题？比如一个 AIops 的应用，他的目标是帮助运维发现线上问题，定位线上问题，解决线上问题？或者是一个智能的发布系统，智能灰度进度，及时发现问题，并快速回滚？ +## 什么才算"完成"一个 AI 应用？ -因此目标可以定义为 "解决" 问题的标准，AI 输出了什么样的内容才算帮助我们解决了问题，关于这个标准，我大概总结出以下几点： +**核心标准**:"问题解决完整性" ———— 应用是否真正解决了设计之初要解决的核心问题。 -1. 准确性：AI 输出的结果是否正确，幻觉率是否能降到最低 -2. 有效性：AI 输出的内容，是否能够达成目标 -3. 一致性：AI 是否按照我们要求输出的规格稳定输出 +这涉及多个层次和维度的工作: -## 如何赋能模型解决问题？ +### 1. 领域定制:将通用能力转为专用能力 -往往从一个裸模型到一个有价值的产品，是需要我们做非常多工作的，这里有比较多可以用的工具/手段，比如说： +这需要我们综合考虑多种手段,使得模型在特定领域、特定任务中表现得更好: -1. RAG (Retrieval-Augmented Generation): 检索增强生成。通过检索外部知识源的信息来辅助大模型生成更准确、相关的回答。 -2. MCP / Function Calling: 模型调用规划/函数调用。指让大模型具备规划、决策、调用工具（API）来完成复杂任务的能力。 -3. Workflow / Pipeline: 工作流/管道。指将多个处理步骤（如数据处理、模型调用、结果后处理）按顺序连接起来形成自动化流程。 -4. Prompt Engineering: 提示词工程。通过精心设计输入提示（Prompt）来引导大模型产生期望的输出。 -5. Context Management: 上下文管理。在多轮对话中有效管理和利用历史交互信息。 +- **提示工程(Prompt Engineering)**:设计有效的提示词模板 +- **RAG(检索增强生成)**:通过检索外部知识库补充上下文 +- **微调(Fine-tuning)**:使用领域数据训练模型,使其更适应特定任务 +- **特定领域的工具调用**:让模型能够在需要时使用外部工具获取信息或执行操作 -但这套工具箱我们并不是拿来主义，不是把所有都装备上，这个 AI 应用就是最好的，而是根据我们的需求，有选择性的，选择一个或多个，能帮助 AI 应用的工具，组合在一块。只有能达成目标的最佳工具才会被选择，甚至可能变种相应的一些技术手段，以达成我们产品的目标为导向。比如本次实训营有一组同学做的 AI 画板，利用 AI 给画板赋能，让画板可以快速且准确得产出游戏素材，该组同学采用提示词工程 + 变种的 RAG 技术，通过比较 Embedding 历史图画和 Prompt 提示词，快速得到多张符合用户需求的图片，来改善用户体验。 +### 2. 应用级架构:构建可靠的业务逻辑 -## 结束语：从模型玩家到问题解决者 +AI 模型只是应用的一部分,完整的应用还需要: -调通模型API是入门AI应用开发的第一步，值得肯定，但这只是拿到了钥匙。真正的挑战和价值在于：如何利用AI这把钥匙，精准地打开特定领域问题的大门，并构建出一条顺畅的解决路径。RAG、MCP、Workflow、Prompt Engineering等技术，是你工具箱里的关键利器，根据你的目标，合理的选择最合适自己的工具，并落地为有价值的解决方案。当你不再仅仅满足于"模型有反应"，而是执着于"问题真被解决"时，你就从一个模型的调用者，成长为真正的 AI 应用构建者和问题解决者。这里也预祝本次实训营的同学们可以完成一个能解决问题的AI应用！ +- **业务逻辑封装**:将模型能力与业务流程整合 +- **数据管理**:如何存储、更新、管理相关数据 +- **多模块协同**:多个模型或模块如何配合工作 +- **错误处理与容错**:当模型输出不符合预期时如何处理 + +### 3. 用户体验:让技术真正为人所用 + +即使技术上完成了,如果用户体验不佳,应用也难以称得上"完成": + +- **交互设计**:用户如何与系统交互?是对话式还是结构化的? +- **响应速度**:系统能否在合理时间内给出响应? +- **输出质量**:输出的内容是否清晰、准确、有用? +- **反馈机制**:用户能否对结果进行反馈和纠正? + +### 4. 工程化:从演示到生产 + +这是很多同学最容易忽视但又至关重要的部分: + +- **可靠性**:系统在各种情况下是否稳定? +- **可扩展性**:能否处理更大规模的请求? +- **可维护性**:代码是否易于理解和修改? +- **可观测性**:能否监控系统运行状态?能否定位问题? + +### 5. 迭代优化:基于反馈持续改进 + +应用上线不是终点,而是起点: + +- **数据收集**:收集用户使用数据 +- **效果评估**:客观评估应用的实际效果 +- **持续优化**:基于反馈不断改进 + +## 实践建议 + +1. **明确问题定义** + - 在开始前,清晰定义要解决什么问题 + - 设定可衡量的完成标准 + - 识别核心用户和使用场景 + +2. **分阶段推进** + - MVP(最小可行产品):先实现核心功能 + - 迭代优化:逐步完善 + - 避免过度设计 + +3. **重视工程实践** + - 代码规范 + - 测试覆盖 + - 文档完善 + +4. **保持用户视角** + - 定期收集用户反馈 + - 关注实际使用效果 + - 持续优化用户体验 + +## 结语 + +"完成"一个 AI 应用不是简单地调通大模型接口,而是: +- 将通用能力转化为领域专用能力 +- 构建完整的应用架构 +- 打磨良好的用户体验 +- 实现工程化的生产系统 +- 基于反馈持续迭代优化 + +只有当应用真正解决了用户的实际问题,并能够稳定、可靠地运行时,我们才能说这个应用是"完成"的。 + +在 1024 实训营,我们期待看到的不仅是技术演示,更是真正能够解决实际问题的完整应用。加油! diff --git a/website/blog/2025-02-08-understanding-llgo-compiler-through-type-system.md b/website/blog/2025-02-08-understanding-llgo-compiler-through-type-system.md index 1212591..0e1ada0 100644 --- a/website/blog/2025-02-08-understanding-llgo-compiler-through-type-system.md +++ b/website/blog/2025-02-08-understanding-llgo-compiler-through-type-system.md @@ -1,10 +1,18 @@ --- slug: understanding-llgo-compiler-through-type-system -title: "从类型系统理解 LLGo 编译器的实现" -authors: [techcamp] -tags: [architecture, career, compiler, engineering, go, llgo, python] +title: 从类型系统理解 LLGo 编译器的实现 +authors: +- techcamp +tags: +- architecture +- career +- compiler +- engineering +- go +- llgo +- python date: 2025-02-08 -description: "编程语言的类型系统可以分为编译时类型系统（程序编译阶段进行静态类型检查的机制）和运行时类型系统（程序执行期间动态管理类型信息的机制）。" +description: 编程语言的类型系统可以分为编译时类型系统（程序编译阶段进行静态类型检查的机制）和运行时类型系统（程序执行期间动态管理类型信息的机制）。 --- 编程语言的类型系统可以分为编译时类型系统（程序编译阶段进行静态类型检查的机制）和运行时类型系统（程序执行期间动态管理类型信息的机制）。 diff --git a/website/blog/2025-02-14-insights-on-architecture-design.md b/website/blog/2025-02-14-insights-on-architecture-design.md index 08a52ca..bf232d7 100644 --- a/website/blog/2025-02-14-insights-on-architecture-design.md +++ b/website/blog/2025-02-14-insights-on-architecture-design.md @@ -1,10 +1,18 @@ --- slug: insights-on-architecture-design -title: "关于架构设计的几点认知体会" -authors: [techcamp] -tags: [ai, architecture, career, compiler, engineering, go, xgo] +title: 关于架构设计的几点认知体会 +authors: +- techcamp +tags: +- ai +- architecture +- career +- compiler +- engineering +- go +- xgo date: 2025-02-14 -description: "一提到架构，很多人脑海中浮现的可能是高并发、高可用、微服务、分布式这些听起来就很\"技术\"的词汇。似乎只有那些处理海量数据、支撑千万用户的系统才需要做架构设计，而日常的业务开发，就是按需求写代码，哪里需要什么架构？" +description: 一提到架构，很多人脑海中浮现的可能是高并发、高可用、微服务、分布式这些听起来就很技术的词汇。似乎只有那些处理海量数据、支撑千万用户的系统才需要做架构设计，而日常的业务开发，就是按需求写代码，哪里需要什么架构？ --- 架构设计，在很多人眼里是个高大上的话题。 diff --git a/website/blog/2025-02-16-spx-algorithm-building-multimodal-search-service.md b/website/blog/2025-02-16-spx-algorithm-building-multimodal-search-service.md index 53fb6aa..be22ebe 100644 --- a/website/blog/2025-02-16-spx-algorithm-building-multimodal-search-service.md +++ b/website/blog/2025-02-16-spx-algorithm-building-multimodal-search-service.md @@ -1,10 +1,15 @@ --- slug: spx-algorithm-building-multimodal-search-service -title: "SPX-Algorithm：构建多模态搜索服务的一些心得" -authors: [techcamp] -tags: [ai, architecture, best-practices, engineering, go] +title: SPX-Algorithm：构建多模态搜索服务的一些心得 +authors: +- techcamp +tags: +- ai +- architecture +- engineering +- go date: 2025-02-16 -description: "也是快到结营阶段了，关于我在实训营期间负责的 SPX-Algorithm 这个项目模块的设计思路，想着写个分享记录一下这段时间的心得体会。这个项目说起来其实就是个图文搜索服务，但做下来发现里面还挺有意思的，尤其是在架构设计和工程实践方面踩了不少坑，也有一些收获。" +description: 也是快到结营阶段了，关于我在实训营期间负责的 SPX-Algorithm 这个项目模块的设计思路，想着写个分享记录一下这段时间的心得体会。这个项目说起来其实就是个图文搜索服务，但做下来发现里面还挺有意思的，尤其是在架构设计和工程实践方面踩了... --- ## 写在前面 diff --git a/website/blog/2025-02-18-code-is-not-core-decision-layers-in-xlink-project.md b/website/blog/2025-02-18-code-is-not-core-decision-layers-in-xlink-project.md index 925397a..89451e3 100644 --- a/website/blog/2025-02-18-code-is-not-core-decision-layers-in-xlink-project.md +++ b/website/blog/2025-02-18-code-is-not-core-decision-layers-in-xlink-project.md @@ -1,10 +1,17 @@ --- slug: code-is-not-core-decision-layers-in-xlink-project -title: "代码不是核心：从 XLink 项目看产品开发的决策层次" -authors: [techcamp] -tags: [ai, architecture, best-practices, career, engineering, go] +title: 代码不是核心：从 XLink 项目看产品开发的决策层次 +authors: +- techcamp +tags: +- ai +- architecture +- career +- engineering +- go date: 2025-02-18 -description: "在正在进行的 1024 实训营中，我们团队开发了 [XLink](https://github.com/goplus/builder/tree/trailhead_sharing) 项目，一个旨在让 [XBuilder](https://xbuilder.com/) 分享更丝滑的产品。通过这个项目的..." +description: 在正在进行的 1024 实训营中，我们团队开发了 [XLink](https://github.com/goplus/builder/tree/trailhead_sharing) + 项目，一个旨在让 [XBuilder](https://x... --- 在正在进行的 1024 实训营中，我们团队开发了 [XLink](https://github.com/goplus/builder/tree/trailhead_sharing) 项目，一个旨在让 [XBuilder](https://xbuilder.com/) 分享更丝滑的产品。通过这个项目的实践，我深刻意识到一个被很多程序员忽视的真相：**在整个产品开发流程中，代码的具体实现往往是最不重要的环节。** diff --git a/website/blog/2025-02-20-llpyg-bridge-for-llgo-python-integration.md b/website/blog/2025-02-20-llpyg-bridge-for-llgo-python-integration.md index 9dd2d81..d77780e 100644 --- a/website/blog/2025-02-20-llpyg-bridge-for-llgo-python-integration.md +++ b/website/blog/2025-02-20-llpyg-bridge-for-llgo-python-integration.md @@ -1,10 +1,19 @@ --- slug: llpyg-bridge-for-llgo-python-integration -title: "llpyg: LLGo 快速集成 Python 生态的桥梁" -authors: [techcamp] -tags: [ai, career, compiler, engineering, go, llgo, python] +title: 'llpyg: LLGo 快速集成 Python 生态的桥梁' +authors: +- techcamp +tags: +- ai +- career +- compiler +- engineering +- go +- llgo +- python date: 2025-02-20 -description: "[LLGo](https://github.com/goplus/llgo) 是一款基于 LLVM 的 Go 编译器，通过 LLVM 为 Go 语言整合了 C 和 Python 语言生态，让开发者可以更工程化地在 Go 中使用海量的 Python 生态库，比如直接使用 numpy、torch 等库。" +description: '[LLGo](https://github.com/goplus/llgo) 是一款基于 LLVM 的 Go 编译器，通过 LLVM 为 + Go 语言整合了 C 和 Python 语言生态，让开发者可以更工程化地在 Go 中使用海量的 Pyt...' --- ## 前言