<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>1sxa12のブログ</title>
<link>https://ameblo.jp/1sxa12/</link>
<atom:link href="https://rssblog.ameba.jp/1sxa12/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>ブログの説明を入力します。</description>
<language>ja</language>
<item>
<title>LLM Prompt 工程：稳定输出的实用写法</title>
<description>
<![CDATA[ <p># LLM Prompt 工程：稳定输出的实用写法</p><p>## 目标</p><p>好的 Prompt 不是华丽措辞，而是把任务边界、输入、输出格式与失败条件说清楚。</p><p>## 模板结构</p><p>1. **角色与目标**：你要完成什么<br>2. **输入材料**：上下文、约束、禁止事项<br>3. **输出契约**：字段、长度、语言、示例<br>4. **自检步骤**：生成后必须核对的清单</p><p>## 示例</p><p>```text<br>你是技术编辑。根据给定草稿输出发布用正文。<br>要求：<br>- 中文<br>- 保留代码块<br>- 标题不超过 40 字<br>- 末尾给 3 条行动建议<br>若信息不足，先列出需要补充的问题，不要编造事实。<br>```</p><p>## 调试方法</p><p>- 固定温度与模型版本做 A/B<br>- 一次只改一个约束<br>- 用失败样例回归，而不是只看成功样例</p><p>## 小结</p><p>Prompt 工程的核心是“可复现”。把期望写成契约，模型表现才会稳定到能进生产流程。</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972443397.html</link>
<pubDate>Sun, 12 Jul 2026 03:24:06 +0900</pubDate>
</item>
<item>
<title>远程协作习惯：让异步团队保持节奏</title>
<description>
<![CDATA[ <p># 远程协作习惯：让异步团队保持节奏</p><p>## 问题</p><p>远程团队最常见的失败不是工具，而是缺少可预期的沟通节奏。消息轰炸与长时间无回复会同时出现。</p><p>## 可落地的习惯</p><p>1. **书面优先**：决策写进文档，会议只处理歧义。<br>2. **状态可见**：每日简短更新“在做什么 / 卡在哪里 / 下一步”。<br>3. **时区友好**：异步默认，同步会议给出议程与结论。<br>4. **深度工作块**：每天保留 2–3 小时不打断时段。<br>5. **回顾循环**：双周回顾流程摩擦，而不是只回顾业务指标。</p><p>## 工具建议</p><p>- 任务：单一来源（Issue / 看板）<br>- 文档：可搜索、有 owner、有最后更新时间<br>- 沟通：紧急才 @，常规走文档评论</p><p>## 小结</p><p>远程效率来自“约定”，不是来自“更勤快点消息”。把默认路径做成异步，同步才会更值钱。</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972443396.html</link>
<pubDate>Sun, 12 Jul 2026 03:24:02 +0900</pubDate>
</item>
<item>
<title>PostgreSQL 索引策略：少建、建对、会验证</title>
<description>
<![CDATA[ <p># PostgreSQL 索引策略：少建、建对、会验证</p><p>## 先测量，再加索引</p><p>没有慢查询证据就加索引，通常只会拖慢写入、膨胀磁盘。先看 `pg_stat_statements` 与 `EXPLAIN (ANALYZE, BUFFERS)`。</p><p>## 常见有效模式</p><p>- **等值过滤**：`WHERE user_id = $1` → B-Tree 单列索引<br>- **组合条件**：高频 `a = ? AND b = ?` → 复合索引，把选择性更高的列放前面<br>- **排序分页**：`ORDER BY created_at DESC` 与过滤列一起设计覆盖索引<br>- **模糊搜索**：前缀匹配可用 `text_pattern_ops`；全文检索考虑 GIN</p><p>## 验证清单</p><p>1. 索引是否被使用（`Index Scan` / `Bitmap Index Scan`）<br>2. 写入路径是否明显变慢<br>3. 是否存在重复或前缀可替代的冗余索引</p><p>## 小结</p><p>好的索引策略是“为真实查询买单”，而不是“为表上每一列买单”。定期清理无用索引，和新增索引一样重要。</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972443393.html</link>
<pubDate>Sun, 12 Jul 2026 03:23:57 +0900</pubDate>
</item>
<item>
<title>Go 并发编程：从 goroutine 到 channel 的实战模式</title>
<description>
<![CDATA[ <p># Go 并发编程：从 goroutine 到 channel 的实战模式</p><p>## 引言</p><p>Go 语言以其简洁优雅的并发模型著称。`goroutine` 与 `channel` 的组合让开发者可以用极少的代码实现复杂的并发逻辑。本文将介绍几种在生产环境中常用的并发模式。</p><p>## Worker Pool 模式</p><p>当需要处理大量任务但又不希望无限制地创建 goroutine 时，Worker Pool 是最佳选择。</p><p>```go<br>func workerPool(jobs &lt;-chan int, results chan&lt;- int, workerCount int) {<br>    var wg sync.WaitGroup<br>    for i := 0; i &lt; workerCount; i++ {<br>        wg.Add(1)<br>        go func() {<br>            defer wg.Done()<br>            for job := range jobs {<br>                results &lt;- process(job)<br>            }<br>        }()<br>    }<br>    wg.Wait()<br>    close(results)<br>}<br>```</p><p>这种模式可以有效控制资源占用，避免因 goroutine 过多导致的调度开销。</p><p>## Fan-out / Fan-in</p><p>将一个任务拆分给多个 worker 并行处理（fan-out），再把结果合并（fan-in），是数据流水线中常见的优化手段。</p><p>关键点在于：<br>- 每个 fan-out goroutine 写入独立的 channel<br>- fan-in 阶段使用 `sync.WaitGroup` 协调关闭</p><p>## Context 取消</p><p>`context.Context` 提供了统一的取消信号传递机制。任何长时间运行的 goroutine 都应该监听 `ctx.Done()`，确保父任务取消时能够及时退出。</p><p>## 小结</p><p>掌握 Worker Pool、Fan-out/Fan-in 与 Context 取消，是写出可维护 Go 并发代码的基础。建议在真实项目中先小范围试点，再逐步推广。</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972443390.html</link>
<pubDate>Sun, 12 Jul 2026 03:23:47 +0900</pubDate>
</item>
<item>
<title>LLM Prompt 工程：稳定输出的实用写法</title>
<description>
<![CDATA[ <p># LLM Prompt 工程：稳定输出的实用写法</p><p>## 目标</p><p>好的 Prompt 不是华丽措辞，而是把任务边界、输入、输出格式与失败条件说清楚。</p><p>## 模板结构</p><p>1. **角色与目标**：你要完成什么<br>2. **输入材料**：上下文、约束、禁止事项<br>3. **输出契约**：字段、长度、语言、示例<br>4. **自检步骤**：生成后必须核对的清单</p><p>## 示例</p><p>```text<br>你是技术编辑。根据给定草稿输出发布用正文。<br>要求：<br>- 中文<br>- 保留代码块<br>- 标题不超过 40 字<br>- 末尾给 3 条行动建议<br>若信息不足，先列出需要补充的问题，不要编造事实。<br>```</p><p>## 调试方法</p><p>- 固定温度与模型版本做 A/B<br>- 一次只改一个约束<br>- 用失败样例回归，而不是只看成功样例</p><p>## 小结</p><p>Prompt 工程的核心是“可复现”。把期望写成契约，模型表现才会稳定到能进生产流程。</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972443025.html</link>
<pubDate>Sun, 12 Jul 2026 03:01:39 +0900</pubDate>
</item>
<item>
<title>远程协作习惯：让异步团队保持节奏</title>
<description>
<![CDATA[ <p># 远程协作习惯：让异步团队保持节奏</p><p>## 问题</p><p>远程团队最常见的失败不是工具，而是缺少可预期的沟通节奏。消息轰炸与长时间无回复会同时出现。</p><p>## 可落地的习惯</p><p>1. **书面优先**：决策写进文档，会议只处理歧义。<br>2. **状态可见**：每日简短更新“在做什么 / 卡在哪里 / 下一步”。<br>3. **时区友好**：异步默认，同步会议给出议程与结论。<br>4. **深度工作块**：每天保留 2–3 小时不打断时段。<br>5. **回顾循环**：双周回顾流程摩擦，而不是只回顾业务指标。</p><p>## 工具建议</p><p>- 任务：单一来源（Issue / 看板）<br>- 文档：可搜索、有 owner、有最后更新时间<br>- 沟通：紧急才 @，常规走文档评论</p><p>## 小结</p><p>远程效率来自“约定”，不是来自“更勤快点消息”。把默认路径做成异步，同步才会更值钱。</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972443023.html</link>
<pubDate>Sun, 12 Jul 2026 03:01:35 +0900</pubDate>
</item>
<item>
<title>PostgreSQL 索引策略：少建、建对、会验证</title>
<description>
<![CDATA[ <p># PostgreSQL 索引策略：少建、建对、会验证</p><p>## 先测量，再加索引</p><p>没有慢查询证据就加索引，通常只会拖慢写入、膨胀磁盘。先看 `pg_stat_statements` 与 `EXPLAIN (ANALYZE, BUFFERS)`。</p><p>## 常见有效模式</p><p>- **等值过滤**：`WHERE user_id = $1` → B-Tree 单列索引<br>- **组合条件**：高频 `a = ? AND b = ?` → 复合索引，把选择性更高的列放前面<br>- **排序分页**：`ORDER BY created_at DESC` 与过滤列一起设计覆盖索引<br>- **模糊搜索**：前缀匹配可用 `text_pattern_ops`；全文检索考虑 GIN</p><p>## 验证清单</p><p>1. 索引是否被使用（`Index Scan` / `Bitmap Index Scan`）<br>2. 写入路径是否明显变慢<br>3. 是否存在重复或前缀可替代的冗余索引</p><p>## 小结</p><p>好的索引策略是“为真实查询买单”，而不是“为表上每一列买单”。定期清理无用索引，和新增索引一样重要。</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972443022.html</link>
<pubDate>Sun, 12 Jul 2026 03:01:30 +0900</pubDate>
</item>
<item>
<title>Go 并发编程：从 goroutine 到 channel 的实战模式</title>
<description>
<![CDATA[ <p># Go 并发编程：从 goroutine 到 channel 的实战模式</p><p>## 引言</p><p>Go 语言以其简洁优雅的并发模型著称。`goroutine` 与 `channel` 的组合让开发者可以用极少的代码实现复杂的并发逻辑。本文将介绍几种在生产环境中常用的并发模式。</p><p>## Worker Pool 模式</p><p>当需要处理大量任务但又不希望无限制地创建 goroutine 时，Worker Pool 是最佳选择。</p><p>```go<br>func workerPool(jobs &lt;-chan int, results chan&lt;- int, workerCount int) {<br>    var wg sync.WaitGroup<br>    for i := 0; i &lt; workerCount; i++ {<br>        wg.Add(1)<br>        go func() {<br>            defer wg.Done()<br>            for job := range jobs {<br>                results &lt;- process(job)<br>            }<br>        }()<br>    }<br>    wg.Wait()<br>    close(results)<br>}<br>```</p><p>这种模式可以有效控制资源占用，避免因 goroutine 过多导致的调度开销。</p><p>## Fan-out / Fan-in</p><p>将一个任务拆分给多个 worker 并行处理（fan-out），再把结果合并（fan-in），是数据流水线中常见的优化手段。</p><p>关键点在于：<br>- 每个 fan-out goroutine 写入独立的 channel<br>- fan-in 阶段使用 `sync.WaitGroup` 协调关闭</p><p>## Context 取消</p><p>`context.Context` 提供了统一的取消信号传递机制。任何长时间运行的 goroutine 都应该监听 `ctx.Done()`，确保父任务取消时能够及时退出。</p><p>## 小结</p><p>掌握 Worker Pool、Fan-out/Fan-in 与 Context 取消，是写出可维护 Go 并发代码的基础。建议在真实项目中先小范围试点，再逐步推广。</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972443015.html</link>
<pubDate>Sun, 12 Jul 2026 03:01:10 +0900</pubDate>
</item>
<item>
<title>AutoPost正式验收 20260712-012205</title>
<description>
<![CDATA[ <p>这是 AutoPost 正式公开发布验收文章。</p><p>用于模拟客户在软件中一键发布到 Ameblo。</p><p>时间: 20260712-012205</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972442363.html</link>
<pubDate>Sun, 12 Jul 2026 02:22:08 +0900</pubDate>
</item>
<item>
<title>AutoPost正式验收 20260712-012144</title>
<description>
<![CDATA[ <p>这是 AutoPost 正式公开发布验收文章。</p><p>用于模拟客户在软件中一键发布到 Ameblo。</p><p>时间: 20260712-012144</p>
]]>
</description>
<link>https://ameblo.jp/1sxa12/entry-12972442360.html</link>
<pubDate>Sun, 12 Jul 2026 02:21:48 +0900</pubDate>
</item>
</channel>
</rss>
