⭐️ Shopify 網站開發服務(給品牌)
https://job.turn.tw/shopify-services

⭐️ 川川電商(阿川創立的全客製電商品牌)
https://chuanchuan.tw

⭐️ 台灣 Shopify 商家交流 LINE 群(非官方)
https://line.me/ti/g2/PZ_1LILWVWWuzZQ50HNpYA-A3k6QXWF6znqoBQ

⭐️ 台灣 Shopify 開發者 LINE 群(非官方)
https://line.me/ti/g2/YUasX5K3CJ4QdIx76zppjHlh3-q8w-xkSyK1LA
登入次數:1,102 次
註冊於2022年11月28日
  發表了 636 篇貼文
  新增了 1,267 則留言
  貼文共 1,226,516 次瀏覽
全部留言

用 hermes agent 幫忙自動上網找活動資料

非常神奇 網站的 ui for agent 是這樣製作的 --- > 很好 可以投稿&審核了 > 新增一組 api endpoint > 讓我的 hermes agent 可以上網找活動、直接投稿 如何呢? > 問題一、 > 要如何讓 hermes 知道 正確的 api format 比方說欄位、以及可接受內容 > 問題二、 > 如何避免重複投稿 是否提供一個 list all events / registrations 即可 > 對了 找到圖片的話 hermes 會需要 upload to imgur 我也提供一個 api 來支援嗎 > 給我一組 prompt 讓 coding agent 做完上述內容吧 --- # Implement Hermes Agent Submission API Add a small authenticated API for an external Hermes AI agent to discover the API contract, inspect existing records, and submit new events and registrations for human review. The existing website already supports normal user submissions and admin review. Reuse the existing domain models, validation rules, enums/constants, image handling, and review workflow wherever possible. Do not create a parallel submission system unless necessary. Before implementing, inspect the existing: - `events` / `event_dates` - `registrations` - submission flow - admin review flow - validation / FormRequest classes - sport and region constants/enums - image storage logic - API documentation setup - authentication conventions Keep the implementation simple. ## Goal Hermes should be able to: 1. Read the API specification and understand valid fields and enum values. 2. Fetch existing events and registrations to avoid duplicate submissions. 3. Submit a new event. 4. Submit a new registration. 5. Provide a remote source image URL when submitting. 6. Have the backend download and store that image using the application's existing image infrastructure. 7. Never publish content directly. All Hermes submissions must enter the existing human review workflow. --- # Authentication Create a simple Bearer-token authentication mechanism suitable for one trusted internal agent. Use environment/configuration rather than storing the token in source code. For example: ```env HERMES_API_TOKEN= ``` Expose it through the appropriate config file. All `/api/agent/*` endpoints must require this authentication. Return standard JSON `401` responses for invalid authentication. Do not introduce OAuth, Sanctum, API client management, or other unnecessary infrastructure unless the project already uses it and reuse is clearly simpler. --- # API endpoints Implement: ```text GET /api/agent/events POST /api/agent/events GET /api/agent/registrations POST /api/agent/registrations ``` Also make sure the existing OpenAPI/API documentation exposes these endpoints and their schemas in machine-readable form. If the project already exposes something like: ```text /api/openapi.json ``` reuse it. Otherwise expose the generated OpenAPI JSON in the simplest way consistent with the project's existing API documentation tooling. --- # GET existing records These endpoints exist primarily so Hermes can detect previously submitted content before creating another submission. ```text GET /api/agent/events GET /api/agent/registrations ``` Return only fields useful for duplicate detection. Do not return the complete models. Registration should return the equivalent relevant fields. Include both published records and records currently waiting for review so Hermes does not repeatedly submit something that is already pending. Past records do not need to be returned if the existing application intentionally hides/removes them from active data. For the current MVP, returning all relevant records is acceptable. Do not implement pagination, vector search, fuzzy search, embeddings, or a dedicated duplicate-check endpoint yet. --- # Duplicate protection Hermes will perform semantic duplicate detection itself by inspecting the GET responses. The server should additionally implement a cheap deterministic safety check. At minimum, if the normalized `source_url` already belongs to an existing or pending record of the same domain type, reject the submission with: ```http 409 Conflict ``` Example response: ```json { "message": "Possible duplicate submission.", "existing": { "public_id": "01K...", "title": "2026 台灣柔術公開賽" } } ``` Normalize URLs reasonably before comparison where appropriate, for example obvious trailing-slash differences. Do NOT build sophisticated fuzzy duplicate detection. --- # POST event Implement: ```text POST /api/agent/events ``` The request schema should mirror the existing event submission/domain model. Do not blindly use this example as the authoritative schema. Inspect the existing Event model, user submission form, migrations, constants/enums, and validation rules first, then make the API consistent with the real application. The OpenAPI schema must explicitly document: - required fields - nullable fields - types - date format - valid `type` values - valid `sports` values - valid `region` values - valid `admission_type` values - examples where useful Hermes should be able to construct a valid request from OpenAPI alone. --- # POST registration Implement: ```text POST /api/agent/registrations ``` Follow the same principles. Inspect the existing Registration model/schema and reuse its actual fields and validation. Do not force Event-specific fields into Registration if they do not belong there. --- # Image ingestion Do NOT expose Imgur or any storage-provider credentials to Hermes. Do NOT require Hermes to upload the image separately. The POST endpoints should accept: ```text thumbnail_source_url ``` This is the public URL of the original image discovered by Hermes. The backend should: ```text thumbnail_source_url ↓ download image ↓ validate response / MIME / file size ↓ store using existing application image infrastructure ↓ save resulting thumbnail_path ``` If the project currently uses Imgur, keep Imgur behind this backend abstraction. Hermes should never need to know whether images are stored on Imgur, S3, R2, local storage, etc. Reuse existing image upload/storage services if available. Add reasonable safeguards against bad remote image input: - only `http` / `https` - valid image MIME types - reasonable maximum download size - request timeout - reject failed downloads - do not trust the filename extension Also protect the remote fetch against obvious SSRF risks: do not allow localhost, loopback, private/internal network addresses, link-local addresses, or other non-public destinations. Avoid building a large generic media subsystem. --- # Review workflow This is important: **Hermes must never be able to publish an Event or Registration.** Agent-created records must enter the same pending/draft state used by normal submissions and appear in the existing admin review interface. The API must NOT accept fields such as: ```text status published_at approved_at ``` from Hermes. Status must be determined server-side. Reuse the existing submission/review workflow rather than creating an agent-specific review UI. --- # Agent attribution If the existing submission architecture has an appropriate place to identify the submitter/source, record that the submission came from Hermes. Prefer the smallest clean change consistent with the current architecture. For example conceptually: ```text submitted_by_type = agent submitted_by = hermes ``` Do not add these exact columns blindly if the current schema has a better mechanism. The admin should ideally be able to tell that a pending submission came from Hermes. 我看 agent 提交的 就讓 user_id null 即可吧 --- # Validation responses Make validation errors useful to an AI client. Use standard `422` JSON responses and expose allowed enum values where practical. Example: ```json { "message": "Validation failed.", "errors": { "sports.0": [ "Invalid sport. Allowed values: boxing, mma, muay_thai, kickboxing, bjj, wrestling." ] } } ``` Do not maintain a second hard-coded list solely for the API. Reuse the application's authoritative constants/enums. --- # OpenAPI The OpenAPI document is the authoritative machine-readable contract for Hermes. Make sure it accurately documents: ```text GET /api/agent/events POST /api/agent/events GET /api/agent/registrations POST /api/agent/registrations ``` including Bearer authentication. A fresh agent reading the OpenAPI document should be able to determine: - which endpoints exist - authentication requirements - request fields - required vs optional fields - valid enum values - expected response formats - validation errors - duplicate response (`409`) Avoid maintaining a separate manually duplicated Hermes schema if the existing OpenAPI tooling can derive it from application validation/schema definitions. --- # Tests Add focused feature tests covering at least: ```text unauthenticated request → 401 authenticated GET events → 200 authenticated GET registrations → 200 valid agent event submission → pending/draft record created valid agent registration submission → pending/draft record created agent cannot control publication status duplicate source_url → 409 invalid sport/region/etc → 422 remote image successfully downloaded and stored invalid remote image → 422 or appropriate client error private/local thumbnail URL rejected Hermes-created submission appears in the same review workflow as normal submissions ``` Mock external HTTP/image requests in tests. --- # Keep the architecture small This is an MVP for one trusted Hermes agent. Do NOT add: - embeddings - vector databases - fuzzy duplicate services - queues unless already needed by existing image handling - OAuth - complex API client management - separate Hermes database tables - separate agent review system - separate image upload endpoint - agent publishing capability Prefer existing application abstractions and conventions. After implementation: 1. Run relevant tests. 2. Run formatting/static analysis used by this repository. 3. Show the final endpoint list. 4. Show an example authenticated Event POST request. 5. Show an example Registration POST request. 6. Show where Hermes can retrieve the machine-readable OpenAPI specification. 7. Briefly list files changed and any migrations/config/env variables added.


Hermes Agent 成功幫我開始日本市場的行銷了~

results: https://www.reddit.com/r/newsokunomoral/comments/1wd2xua/ https://www.reddit.com/r/lowlevelaware/comments/1wd319c/


好久沒接大公司案子了,真吐血,趕快記錄一下

我一人為主 少數情況會跟朋友一起接案 很偶爾 看專案


前端動畫原來有這樣的套件啊 GSAP

我太久沒碰新潮工具了...


垃圾機器人怎麼拿到高分的!?有點意思

首頁排序 ux 我之後有空再研究改善


垃圾機器人怎麼拿到高分的!?有點意思

他按了1個讚拿到1分


又差點跟客戶吵架

文章列表現在分 `熱門`、`最新` 預設是看熱度 會被`瀏覽量`、`按讚數`影響


我 macbook 用 chrome 打不開 shopify 也打不開 cloudflare WARP

找到問題了 ![](https://i.imgur.com/Byp6h1o.png) Docker Desktop → Settings → Resources → Network `UDP kernel networking` 關掉


Zeabur、Pipee 派比部署、GitHub Pages、Vercel 怎麼選?一篇看懂網站部署平台差異

很好的分享


跟大公司合作時,我其實不是只在做產品

# 報價 ``` 小公司:K × 1.0 中型公司:K × 1.3 大企業:K × 1.5 政府 / 大型組織 / 多部門 / 採購流程重:K × 2.0+ ``` 小公司 / 老闆直接決策 -> K -> 適合 agile、快速動工、邊做邊調。 中型公司 / 有窗口但決策鏈不長 -> K × 1.3 -> 原因是會多一些會議、文件、確認,但還不至於太官僚。 大公司 / 多部門、多窗口、正式驗收 -> K × 1.5 這是最合理的基本盤。 政府、上市櫃、跨國公司、法務採購流程很重 -> K × 2 ~ 2.5 這類案子最可怕的不是開發,是: 前期規格書 投標文件 驗收文件 資安要求 採購流程 會議紀錄 需求凍結 變更管理 保固責任 ``` 中小企業買的是速度。 大企業買的是確定性。 政府標案買的是責任轉移。 ``` 最簡單記法: ``` 有窗口就 +30% 有多部門就 +50% 有採購法務驗收就 +100% ```


跟大公司合作時,我其實不是只在做產品

Agile 適合雙方都有決策權,或至少雙方都能快速替產品結果負責。 否則就會自然退回 waterfall:按規格、按階段、按驗收做事。 大組織不是不能 agile,而是 agile 需要大量內部對齊。當內部對齊成本太高,固定範圍、固定驗收、分階段交付反而比較便宜。 只要對方沒有決策權,就不要賣 agile。 Agile 是決策權充足時的效率工具;Waterfall 是決策權分散時的風險控制工具。


從「能跑」到「敢上線」:談 E2E 測試在現代前端開發的重要性

原來如此 太猛了 謝謝


跟大公司合作時,我其實不是只在做產品

# Waterfall 才是商業常態,Agile 是高信任例外 > Waterfall 其實才是大多數商業合作的預設模式。 > Agile 反而是少數高信任關係下,才比較容易成立的工作方式。 以前我跟新創合作,常常是直接對 CEO。 這種情境下,對方在意的是: - 怎樣最快上線 - 怎樣驗證方向 - 怎樣根據市場反應調整 - 怎樣用有限資源換最大學習速度 所以 Agile 很自然。 因為 CEO 本人就是決策者,也是風險承擔者。 他可以接受第一版不完美,只要能快速驗證。 但一般商業合作不是這樣。 大公司、政府單位、一般企業,通常更在意: - 交付什麼 - 什麼時候交 - 多少錢 - 怎樣算完成 - 怎樣驗收 - 出問題誰負責 這些問題本質上都偏 Waterfall。 所以我以前以為 Agile 比較先進、Waterfall 比較落後。 但現在看起來,更精準的理解應該是: > Agile 是產品開發方法。 > Waterfall 是商業交易介面。 真正的問題不是 Waterfall 爛,而是很多案子其實是: > 用 Waterfall 的價格與驗收,要求 Agile 的彈性。 也就是: - 價格固定 - 時程固定 - 驗收固定 - 但需求可以一直變 - 老闆看了可以一直改 - 還希望都算在原本範圍內 這才是接案地獄。 所以以後要分清楚兩種合作模式。 ## 固定價專案 適合大公司、政府、一般企業。 這種案子應該採用: - 固定範圍 - 固定交付 - 固定驗收 - 固定時程 - 變更另計 這不是落後,而是合理的商業交易方式。 因為客戶買的是確定性。 ## 長期產品合作 適合新創、CEO 直通、高信任客戶。 這種才適合: - 持續迭代 - 每週排優先級 - 根據市場反應調整 - 不斷修正產品方向 但這種合作最好用月費、顧問、retainer 或長期合作模式來賣。 因為 Agile 的本質就是範圍會變。 範圍會變,就不適合用固定價硬包。 ## 結論 以後我會這樣記: > Waterfall 是交易模型。 > Agile 是開發模型。 對外可以是 Waterfall contract。 對內仍然可以 Agile execution。 也就是: > 我內部可以快速迭代,但對客戶暴露出去的介面,要是清楚、穩定、可驗收的。 固定價專案就不要再幻想純 Agile。 真正的 Agile,要用長期合作或月費模式來承載。 否則就會變成: > 客戶買的是固定價格,期待的是無限彈性。


實驗性的 RD agency

## 主機與第三方服務費用 - 可由客戶自行註冊並持有帳號 - 亦可由我們代為管理與設定 - 所有第三方費用將依實際帳單金額轉收,不另加價 > 說明:第三方服務由供應商提供,我們負責協助管理與設定


實驗性的 RD agency

# 維護服務方案(半年合約) ## 核心原則 - 維護 ≠ 開發 - 固定費 + 工時包 - 未使用工時不累積 --- ## 方案 A:基礎維護(低接觸) **NTD 6,000 ~ 10,000 / 月** 包含: - bug 修復(輕量) - server / DB 基本維運 - 每月 1~2 小時內調整 --- ## 方案 B:標準維護(建議) **NTD 12,000 ~ 20,000 / 月** 含 **4~6 小時 / 月** 包含: - bug 修復 - server / DB 維運 - 小幅優化 超出:**NTD 2,000 / hr** --- ## 方案 C:進階維護 **NTD 25,000+ / 月** 含 **8~12 小時 / 月** 包含: - 專屬窗口 - 較快回應 - 架構 / 效能支援 --- ## 不包含(需另報價) - 新功能開發 - UI / UX 大改 - 第三方整合 --- ## SLA(回應時間) - P1:系統無法使用 → 4 小時內回應 - P2:功能異常 → 1~2 天 - P3:一般需求 → 排程處理 --- ## 說明 - 維護費是用來處理錯誤、維持系統穩定 - 新功能與較大修改需另外報價


實驗性的 RD agency

小案 / 低預算: App server:Linode / Hetzner / Vultr Ubuntu DB:同一台 host MySQL + 自動備份 正式商業案: App server:隨便租 Ubuntu DB:Managed MySQL DB 管理原則: - 不提供 web-based DB 管理工具(如 phpMyAdmin) - 僅允許: - 本機 GUI 透過安全連線(SSH / VPN) - CLI(mysql / artisan / migration) - DB 不對 public 開放 - 必須設定: - strong password - IP allowlist(managed DB)


為什麼我現在不安裝 Hermes Agent

really good


實驗性的 RD agency

阿川技術事務所 Akawa Engineering Firm


實驗性的 RD agency

# 接案公司核心架構(精簡版) ## 公式 接案公司 = 案源系統 + 決策系統 + 生產系統 + 品質系統 --- ## 1. 案源系統(Traffic / Leads) 目的:穩定取得案源,不依賴單一平台 - SEO(內容網站 / 工具站) - 社群曝光(Twitter / Reddit / 技術論壇) - 自有流量池(產品、社群、名單) - 案源轉介紹機制 --- ## 2. 決策系統(Scope / Pricing) 目的:避免專案失控,確保利潤 - 報價模板(固定結構) - scope 切分(must / nice / extra) - 變更需求 → 一律重新報價 - 拒絕不合理需求(有標準) --- ## 3. 生產系統(Development) 目的:讓工程師快速產出一致品質 - 技術標準棧(例:Laravel + React + MySQL) - 專案結構規範(資料夾 / 命名 / 分層) - AI 使用規範(prompt / code 生成流程) - 開發流程(PR / commit / review) - 環境標準化(Docker for app, DB 獨立) --- ## 4. 品質系統(Delivery) 目的:確保交付穩定、可驗收 - 交付 checklist(功能 / UI / 邏輯) - code review 規則 - bug 分級與處理流程 - 驗收標準(什麼叫完成) - 上線流程(deploy / rollback / backup) --- ## 核心目標 讓系統達到: 新人進來 → 按規範開發 → 產出 80% lead 補強 → 100% 可交付 --- ## 關鍵護城河 - 案源穩定(不缺案) - scope 控制能力(不爆案) - AI + 開發流程標準化(可擴張)


實驗性的 RD agency

建立一套: ``` 可複製的接案流程 可複製的技術棧 可複製的 scope 控制 可複製的交付品質 ``` 真正的護城河會是: ``` 案源 + 報價能力 + scope 控制 + 品質把關 ``` 可以把整家公司抽象成: ``` 接案公司 = 案源系統 + 決策系統 + 生產系統 + 品質系統 ```


語音版的 threads? learn language & social?

拉空間 放 adsense 廣告 沒登入就會看到廣告 一天收入約1.5美元 呵呵


Harness 工程:不是新詞,而是 Agent 工程終於被講明白了

猛的


Harness 工程:不是新詞,而是 Agent 工程終於被講明白了

乾貨


我居然累積三個專案都被抄襲XD (先簡單紀錄

good job


90% 的程式碼將由 AI 生成──那我們到底還能做什麼?

AI 衝擊!大家一起找解決辦法!


測試2

? 是在測試小龍蝦?


正在評估幫 shopify 客戶 客製化一個 theme

# Shopify Theme 命名簡短指引(mc- 使用版) ## 一句話結論 👉 檔名不用 mc- 👉 前端 namespace 才用 mc- --- ## 不用 mc- 的地方(保持語意清楚) ### 檔名 hero.liquid faq-list.liquid product-showcase.liquid ### snippet 名 button-primary.liquid product-card.liquid ### template 名 product.json page.about.json ### Liquid 變數 product_title faq_items --- ## 應該用 mc- 的地方(避免衝突) ### CSS class(最推薦) mc-hero mc-hero__title mc-faq mc-button ### JS 綁定用 selector / data data-mc-tab data-mc-modal data-mc-drawer ### JS namespace / event window.mcTheme mc:cart-open mc:variant-change ### CSS variables --mc-color-primary --mc-container-width ### id / utility class id="mc-modal" .mc-hidden --- ## 可用可不用 ### asset 檔名 theme-custom.css(建議) mc-theme.css(也可) ### body class mc-theme(推薦) --- ## 最短實務規則 檔名 → 不用 mc- DOM / CSS / JS → 用 mc- 👉 這樣最乾淨、最穩、最好維護


正在評估幫 shopify 客戶 客製化一個 theme

Shopify Dawn(Figma 高還原)開發流程 SOP 適用情境 * 工程師主導 * 單客戶客製 * Figma pixel-perfect 還原 * 約 1 個月交付 核心原則 把 Dawn 當 runtime,不當 UI 基底 Section 完全照 Figma 拆 CSS 主導,Liquid 配合 Theme editor 只開必要設定 一、專案初始化 1. clone + 重建 git git clone [https://github.com/Shopify/dawn.git](https://github.com/Shopify/dawn.git) my-theme cd my-theme rm -rf .git git init 2. 刪首頁 demo sections 可刪 announcement-bar.liquid collage.liquid collapsible-content.liquid collection-list.liquid custom-liquid.liquid email-signup-banner.liquid featured-blog.liquid featured-collection.liquid featured-product.liquid image-banner.liquid image-with-text.liquid multicolumn.liquid multirow.liquid newsletter.liquid rich-text.liquid slideshow.liquid video.liquid 不要刪 main-product.liquid main-cart-items.liquid main-cart-footer.liquid cart-drawer.liquid header.liquid footer.liquid apps.liquid predictive-search.liquid pickup-availability.liquid main-page.liquid main-search.liquid main-collection-product-grid.liquid main-collection-banner.liquid 3. 建立自己的 CSS / JS 入口 assets/ theme-custom.css theme-custom.js 在 layout/theme.liquid 引入 {{ 'theme-custom.css' | asset_url | stylesheet_tag }} {{ 'theme-custom.js' | asset_url | script_tag }} 二、Figma 拆解策略(最重要) 不照 Dawn 拆 完全照 Figma 區塊拆 範例 首頁 hero logo-cloud feature-grid product-showcase testimonial-list faq-list final-cta 建立 sections/ hero.liquid logo-cloud.liquid feature-grid.liquid product-showcase.liquid testimonial-list.liquid faq-list.liquid final-cta.liquid 三、首頁 index.json 結構建議 sections: hero feature-grid product-showcase faq-list final-cta order: hero feature-grid product-showcase faq-list final-cta 四、開發順序(強烈建議) Phase 1 全站骨架 header footer container system spacing system typography button style Phase 2 首頁 hero 主賣點區 商品亮點區 testimonial faq cta Phase 3 Product / Collection product page collection page cart drawer cart page Phase 4 RWD + polish desktop → tablet → mobile 五、CSS 策略 命名建議 .hero .hero__title .hero__image .faq .faq__item 不要 .section .block .module layout system(建議自己做) .container .section .grid .grid--2 .grid--3 六、Theme Editor 策略 只開 image text button label 避免 spacing 控制 layout switch 過多 toggle 七、圖片與效能 圖片 {{ image | image_url: width: 1200 }} lazy load loading="lazy" 八、JS策略 集中 assets/theme-custom.js 九、section 命名規則 不用前綴(不要 mc-) 用語意命名 hero.liquid logo-cloud.liquid feature-grid.liquid product-showcase.liquid faq-list.liquid final-cta.liquid 十、One-Month Sprint 節奏 Week 1 清 Dawn layout header/footer homepage skeleton Week 2 homepage完成 product page Week 3 collection cart search Week 4 RWD animation bugfix QA 最重要一句 不要過度整理 Dawn 直接開始刻 Figma


正在設計一種 shopify theme 主題開發報價範本

sample 1 ``` # Shopify Theme 客製開發專案 專案總價:NT$150,000 ### 2026-03-xx **合約開始|支付訂金 3 萬** > 訂金支付後即開始排程與製作 --- ### 2026-04-30 **交付可正式上線版|支付中期款 6 萬** - 達到可正式上線之品質與使用標準 - 與 Figma 主要版型與結構一致 - RWD 正常(桌機/平板/手機) - 無阻礙使用之重大錯誤 > 達上述標準即視為本階段完成 --- ### 2026-05-31 **優化與保固階段|支付尾款 6 萬** - 複雜動畫補強 - 進階互動優化 - 上線後發現的 bug 修正 > 優化範圍以本案既定設計為限 ```


AI 付費聊天機器人

https://zhuanlan.zhihu.com/p/1931348396406452703


AI 付費聊天機器人

https://letschuhai.com/dc53f0e3


我對 ai 的看法每6個月就大改變一次

good job!


Pattern Note #15:簡單示範 OpenAI Vision API

在重新思考職涯規劃 https://codelove.tw/@howtomakeaturn/post/anNNGa


設計實戰 laravel 教材

同意 LLM 可以算是有史以來 最大規模的 自動剽竊行為 音樂 圖像 文字 ...etc 都躲不過 白領階級 還有多少技能有意義 需要深思


用 ai 翻譯部落格,嘗試接國外的案子

更新: 大多數文章 連索引都沒有 更不可能帶來自然流量 ![](https://i.imgur.com/EOAikMR.png) ![](https://i.imgur.com/gfs8myN.png) 他媽的!事情果然沒那麼簡單 想想也是 現在是 AI 時代 除非已確認有流量 或者有很好的反向連結 否則 根本連索引都不願意


MST 測速:5 秒測完網速,不用再等轉圈圈

我通常都是用 http://fast.com/ 我是覺得夠用


成語群英傳

![](https://i.imgur.com/U90BH1n.jpeg) ![](https://i.imgur.com/7RnEPxn.jpeg) ![](https://i.imgur.com/Ytwl3hV.jpeg) ![](https://i.imgur.com/L1g4wcR.jpeg) ![](https://i.imgur.com/PCIa0ig.jpeg)


成語猜猜

![](https://i.imgur.com/MmUdHes.jpeg) ![](https://i.imgur.com/qQN6Zai.jpeg) ![](https://i.imgur.com/M4avcHT.jpeg) ![](https://i.imgur.com/whVyXSR.jpeg) ![](https://i.imgur.com/ByEkYw6.jpeg) ![](https://i.imgur.com/D03PWPW.jpeg) ![](https://i.imgur.com/rC4jPaY.jpeg) ![](https://i.imgur.com/015T1qF.jpeg)


成語填填字:成語接龍文字遊戲,學成語好幫手

![](https://i.imgur.com/BDfaUT7.jpeg) ![](https://i.imgur.com/gwa9ySP.jpeg) ![](https://i.imgur.com/5559Zv6.jpeg) ![](https://i.imgur.com/K6JeTov.jpeg) ![](https://i.imgur.com/cdqRHZg.jpeg) ![](https://i.imgur.com/8nIPEJ1.jpeg)


成語填填看 - 單字測驗、單字和文字遊戲、大腦訓練和現實遊戲

![](https://i.imgur.com/zdWi0NF.jpeg) ![](https://i.imgur.com/1cBnm6V.jpeg) ![](https://i.imgur.com/tobuHRO.jpeg) ![](https://i.imgur.com/hSXjXh1.jpeg) ![](https://i.imgur.com/xHSjs4J.jpeg)


成語填填看 - 單字測驗、單字和文字遊戲、大腦訓練和現實遊戲

![](https://i.imgur.com/sRYF9Dr.jpeg) ![](https://i.imgur.com/NUlAKr4.jpeg) ![](https://i.imgur.com/rDjnoGT.jpeg)


成語填填看 - 單字測驗、單字和文字遊戲、大腦訓練和現實遊戲

![](https://i.imgur.com/lTuC6DJ.jpeg) ![](https://i.imgur.com/bvixi3o.jpeg) ![](https://i.imgur.com/K28FLnH.jpeg) ![](https://i.imgur.com/sYfdwnN.jpeg) ![](https://i.imgur.com/vfLjwmi.jpeg)


想做個成語小遊戲

https://idiomgame-2b9rnjpd.manus.space/


裁員為什麼先裁技術人員?網友一針見血

agree


Nano Banana Pro 很強,但你要學會寫提示詞才能為所欲為

乾貨


身為資深前端開發人員,我是如何實際使用人工智慧代理的(而且不會破壞生產環境)

agree


開發者與人工智慧:我們正在從程式設計師變成人工智慧管理者嗎?

agree


居然有美國廠商 CTO 詢問我 shopify 任務

補充: 背後技術使用到 https://nango.dev/docs/getting-started/quickstart/embed-in-your-app


創業路上你會開始遇到傻逼,因為其實傻逼早就在你身邊!

不要挑戰人性 不要輕易展現成果 讓身邊的人徒增挫折感 創業路上基本不會有半點掌聲 花時間跟客戶溝通 花時間找資源就好了


實驗一下非嵌入式 shopify app 的串接流程

找 AI 寫的最簡單串接 不確定流程是否為 best practice ``` <?php namespace App\Http\Controllers; use Illuminate\Http\Request; use Illuminate\Support\Facades\Http; class ShopifyController extends Controller { public function index(Request $request) { // Shopify 必定傳入 shop=xxxxx.myshopify.com $shop = $request->query('shop'); if (!$shop) { return 'Missing ?shop=xxxxx.myshopify.com'; } // 從 DB 找現有 token (POC 用 session 模擬) $token = session("token_{$shop}"); // 已安裝 → 直接進入 app 面板 if ($token) { return "已安裝 App,商店 {$shop} 的 Token 是:<br>".$token; } // 尚未安裝 → 跳 OAuth Flow $clientId = '6b7001530576df226f1e8d6773eea438'; $scopes = 'read_products'; // $redirectUri = route('shopify.redirect'); $redirectUri = 'https://demo-connect.turn.tw/redirect'; $authorizeUrl = "https://{$shop}/admin/oauth/authorize?".http_build_query([ 'client_id' => $clientId, 'scope' => $scopes, 'redirect_uri' => $redirectUri, ]); return redirect($authorizeUrl); } public function redirect(Request $request) { $shop = $request->get('shop'); $code = $request->get('code'); if (!$shop || !$code) { return 'Missing shop or code.'; } $clientId = '6b7001530576df226f1e8d6773eea438'; $clientSecret = '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'; // 呼叫 Shopify 換永久 access token $response = Http::post("https://{$shop}/admin/oauth/access_token", [ 'client_id' => $clientId, 'client_secret' => $clientSecret, 'code' => $code, ]); if ($response->failed()) { return 'Token exchange failed: '.$response->body(); } $accessToken = $response->json('access_token'); // POC → 先存在 Session session(["token_{$shop}" => $accessToken]); return redirect('/?shop='.$shop); } } ```